Windows

[Job] Help create the Windows version of Framer – React developer in Amsterdam

TL;DR: Framer are looking for a React developer based in Amsterdam to create the Windows version of the app with help from my team. Apply here.

Framer is only available on OSX

One of the things that annoy me the most is operating system dependence. It is frustrating to see a great new tool you want to use but it isn’t available on your platform. Not everyone can afford Apple hardware or wants to do everything in Windows or Android. I personally use several operating systems and it annoys me that I can’t use the same tool stack. Instead you need to learn different ones for each OS (Keynote/Powerpoint anyone?). It feels like the 90s.

That’s why I was happy when Framer contacted me and asked me to help them find someone to work on the Windows version of their great tool. The great news is that you’re not only going to work for a cool company. You also get to work directly with our team here to ensure that the port is going to be a great product. At Microsoft we have a dedicated team helping people to port apps. This team has deep insight into what to do and what to avoid to create an app that takes advantage of the things Windows 10 offers.

So, if you are:

  • A React Native developer who wants to build a great, well-used app for a big community
  • Have Windows experience and supporting more than Chrome/OSX in your WebView
  • Look for a full-time position in Amsterdam, The Netherlands

Apply now, and we can soon bridge another support gap that that is well over-due.

This is a short time offer, Framer are looking to hire someone ASAP and bring out the Windows version within a few months. The new Framer version is close to Alpha release internally.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Meetup in London: why is Windows not your platform of choice

This Thursday, my colleague Mike Harsh and Keith Rowe (@krow) from Microsoft’s Windows and Devices Group invite you to the Square Pig in London for some drinks and a chat. These two program managers are leading efforts to make Windows-based machines a better place for web development.

I’ve put up a small web site with the info of the meetup and there’s also a Lanyrd page. Many thanks also to London Webstandards for banging the drum.

Whilst I am not affiliated with this group and I can’t be there as I am on my way to JSConf Asia to present, I’d love to see a lot of people go and talk to them. This is a genuine offer to improve what Windows has for web developers and I already gave them quite a bit of feedback on the matter (I am a Mac user…).

I’ve been worried about our Mac fixation as web developers for a while. We preach about supporting all platforms as “it is the web” but a lot of our tooling and best practices are very Mac/Command Line centric.

I know this is a bit last minute, but as it is with London Pubs, you have to spring a grand to get the room for the evening, so please show up and at least make sure this expense ends in the form of food and drinks inside people who Microsoft can learn from.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

On Windows XP and IE6

On Tuesday, Microsoft announced the end of support for Windows XP. For web developers, this meant much rejoicing as we are finally rid of the yoke that is Internet Explorer 6 and can now use all the cool things HTML5, CSS3 and other tech has to offer. Right? Maybe.

xp

When I started web development my first real day-to-day browser was IE4 and then Netscape Navigator Gold moving on to Netscape Communicator 4. I saw the changes of IE5, 5.5 and finally IE6. I was pretty blown away by the abilities IE6 had. You had filters, page transitions, rotation, blurring, animation using marquee and even full-screen applications using the .hta extension. In these applications you had full JScript access to the system, you can read and write files, traverse folders and much more. Small detail: so had attackers as the security model wasn’t the best, but hey, details…

None of this was a standard, and none of it got taken on by other browsers. That probably wasn’t possible as features of browsers were the main differentiator and companies protected their USPs.

IE was never and will never be just a browser: it is an integral part of the operating system itself. For better or worse, Microsoft chose to make the web consumption tool also the file browsing and document display tool. Many of the very – at that time – futuristic features of IE6 were in there as they were needed for Powerpoint-style presentations.

That’s why the end of XP is a light at the end of the tunnel for all those suffering the curse that is IE6. Many users just didn’t bother upgrading their browser as what the OS came with was good enough.

A cracker’s paradise

Of course we now have a security problem: not all XP installs will be replaced and the lack of security patches will result in many a hacked server. Which is scary seeing that many ATMs run on XP and lots of government computers (the UK government alone spent 5.5m GBP on getting extended support for XP as moving on seems to be hard to do with that many machines and that much red tape). XP and IE6 weren’t a nuisance for web developers – they are a real threat to internet security and people’s online identity for a long time now.

The fast innovator in a closed environment dilemma

You can say what you want about IE6 – and it has been a running joke for a long time – having it and having it as the nemesis of web standards based browsers (Opera, Netscape6 and subsequently Firefox) taught us a lot. Having a browser that dared to dabble with applications in HTML years before the W3C widget spec or Adobe Air was interesting. Having a browser in the operating system that naturally was the first thing people clicked to go online helped the internet’s popularity. It didn’t help the internet as a whole though.

The big issue of course was that people didn’t upgrade and the OS didn’t force-upgrade the browser. This meant that companies had a fixed goal to train people on: if it works in IE6, it is good enough for us. That’s why we have hundreds of large systems that only work in IE. Many of those are enterprise systems: CRM, Asset management, Ticketing, CMS, Document management – all these fun things with lots of menus and trees and forms with lots of rules.

Nobody likes using these things. People don’t care for them, they just see them as a necessary thing to do their job and something created by magical hairy pixies called the IT department. When you don’t like something but need to use it any change in it is scary, which is why a lot of attempts to replace these systems with more user-friendly and cross-platform systems is met with murmurings or open revolt. I call this the Stockholm syndrome of interfaces: I suffered it for years, so I must like it, right? All the other stuff means more work.

Back to the browser thing though: The issue wasn’t IE6, the issues were its ubiquity, an audience that wasn’t quite web savvy yet and didn’t crave choice but instead used what was there, and Microsoft’s tooling centering around creating amazing things for IE first and foremost and maybe a fallback for other browsers. The tools locked into IE6 were most of the time not created by web developers, but by developers of .NET, classic ASP, Sharepoint and many other – great – tools for the job at hand. Everything seemed easy, the tools seemed far superior to those that cover several targets and when you stayed inside the ecosystem, things were a breeze. You didn’t even have to innovate yourself – you just waited until the platform added the next amazing feature as part of the build process (this even happened at awesome events that only cost your employer and means you can get an awesome T-Shirt to boot). Sound eerily familiar to what’s happening now in closed platforms and abstracted developer tools, doesn’t it? Look – it’s the future, now – if you use platform x or browser y.

What should we take away from this?

Which brings me to the learning we should take away from these years of building things for a doomed environment: browsers change, operating systems change, form factors change. What we think is state-of-the-art and the most amazing thing right now will be laughable at best or destructive to innovation at worst just a year ahead.

And it is not Microsoft’s fault alone. Microsoft have seen the folly of their ways (OK, with some lawsuits as extra encouragement) and did a great job telling people to upgrade their systems and stop targeting OldIE. They understand that not every developer uses Windows and made testing with virtualisation much easier. They are also much more open in their messaging about what standards new IE supports. If they understand this, we should, too.

Here are the points we should keep in our heads:

  • Bolting a browser into an operating system makes it harder to upgrade it – you see this now in Android stock browsers or iOS. Many of the amazing features of HTML5 need to be poly-filled, not for old IE, but for relatively new browsers that will not get upgraded because the OS can’t get updated (at times on hardware that was $500 just a few months ago)
  • Building software for the current state of the browser is dangerous – especially when you can’t trust the current state to even be stable. Many solutions relying on the webkit prefix functionality already look as silly as a “if (document.layers || document.all) {}” does.
  • Stop pretending you can tell end users what browser to use – this is sheer arrogance. Writing software means dealing with the unknown and preparing for it. Error handling is more important than the success case. Great UX is invisible – the thing just works. Bad error handling creates unhappy users and there is nothing more annoying than being on a pay-by-the-minute connection in a hotel to be told I need to use another browser or update mine. Stop pretending your work is so important people have to change for you if all you need to do is being more creative in your approach.

There are only a few of us unlucky enough to have to support IE6 in a pixel-perfect manner right now. The death of XP wasn’t the big liberation we really needed. And by all means it should not mean that you write web apps and web sites now that rely on bleeding edge technology in newer browsers without testing for it. This will never go away, and it shouldn’t. It makes us craftsmen, it keeps us on the ball. We need to think before we code, and – to me – that is never a bad idea.

The rules did not change:

  • HTML is king – it will display when everything else fails, it will perform amazingly well.
  • Progressive Enhancement means you write for now and for tomorrow – expect things to break, and plan for it, and you can never be surprised.
  • Browser stats are fool’s gold – who cares how many people in Northern America who have a certain statistics package installed use browser x or browser y. What do your end-users use? Optimise for form factors and interaction, not for browsers. These will always change.
  • Writing for one browser helps that one in the competition with others, but it hurts the web as a whole – we’re right now in a breakneck speed rat-race about browser innovation. This yields a lot of great data but doesn’t help developers if the innovations vanish a few versions later. We have jobs to do and projects to deliver. There is not much time to be guinea pigs
  • Real innovation happens when we enhance the platform – we need WebComponents in the browsers, we need WebRTC in browsers, we need a more stable Offline and Local Storage solution. What we don’t need is more polyfills as these tend to become liabilities.

So, RIP XP, thanks for all the hardship and confusion that made us analyse what we do and learn from mistakes. Let’s crack on with it and not build the next XP/IE6 scenario because we like our new shiny toys.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

WebRTC enabled, H.264/MP3 support in Win 7 on by default, Metro UI for Windows 8 + more – Firefox Development Highlights

Time again for looking at the latest progress with Firefox. These posts are part of our Bleeding Edge and Firefox Development Highlights series – take note that most examples only work in Firefox Nightly (and could be subject to change).

WebRTC enabled by default

Previously, you needed to go to about:config in Firefox and set the media.peerconnection.enabled option to true, but now it’s enabled by default. This is a huge step forward, to be able to run WebRTC directly in a web browser without it needing any special settings or configuration.

For more details behind this decision, please read Pref on WebRTC by default.

Want to get started with WebRTC? Then we recommend our article Cross-browser camera capture with getUserMedia/WebRTC.

Metro UI

The new Firefox User Interface for Windows 8 has landed (if you had Firefox Nightly as your default browser, reset that permission to see the new UI).

There are more screenshots available too.

H.264 & MP3 support enabled by default in Windows 7

We talked about H.264 & MP3 support before, and now that support is activated by default.

We are still working on supporting Mac OS X and Linux.

WebAudio API progress

We are working on implementing the WebAudio API, and the first parts of support has just started appearing.

It’s available in about:config in the media.webaudio.enabled preference – set it to true to enable it and be able to access things such as AudioContext.decodeAudioData.

Crypto API: window.crypto.getRandomValues

If you provide an integer-based TypedArray (i.e. Int8Array, Uint8Array, Int16Array, Uint16Array, Int32Array, or Uint32Array), window.crypto.getRandomValues is going fill the array with cryptographically random numbers:

/* assuming that window.crypto.getRandomValues is available */
 
var array = new Uint32Array(10);
window.crypto.getRandomValues(array);
 
console.log("Your lucky numbers:");
for (var i = 0; i < array.length; i++) {
    console.log(array[i]);
}

canvas: ctx.isPointInStroke

This has been uplifted to Firefox 19 Beta.

From the WHATWG mailing list:

“We have recently implemented isPointInStroke(x,y) in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=803124). This is a parallel to isPointInPath(x,y) and returns true if the point is inside the area contained by the stroking of a path.”

JavaScript: Math.imul

Math.imul allows for fast 32-bit integer multiplication with C-like semantics. This feature is useful for projects like Emscripten.

Polyfill:

function imul(a, b) {
    var ah  = (a >>> 16) & 0xffff;
    var al = a & 0xffff;
    var bh  = (b >>> 16) & 0xffff;
    var bl = b & 0xffff;
    // the shift by 0 fixes the sign on the high part
    return (al * bl) + (((ah * bl + al * bh) << 16) >>> 0);
}

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)