You are currently browsing the Christian Heilmann blog archives for March, 2015.
Archive for March, 2015
Last week I was lucky enough to give the opening keynote of the inaugural WROC# event in Wroclaw, Poland. The event, organised by Objectivity was aimed at Microsoft stack based developers and I felt incredibly out of my depth. In essence, I was the Microsoft employee who had much less knowledge about the subject matter than the audience.
I took the opportunity, however, to tell this sort-of-captive audience about the massive need we have in innovating “the other web”. The web these developers work on day-to-day, the web of large corporations on Windows machines who get functionality from framworks, see the front-end as a complex thing to tame and are beholden to browsers that should have been replaced years ago.
My talk slides are on Slideshare.
I also recorded a screencast of the talk and uploaded it to YouTube.
Resources I mentioned in the talk:
- Comscore report on mobile App usage
- Can I use? – showing you the current capabilities different browsers
- Making it easier for Enterprise customers to upgrade to IE11 and Windows 10
- Forrester research paper on the financial benefits of upgrading browsers
- Windows Insider program to test-drive Windows 10
- Request features in Project Spartan or IE11
- Current capability and browser compatibility status of IE
- GoChat showing just how many animations you can put on a single page
- Webpagetest.org to test for and fix performance problems in your site
A few remarks about the event
As you know, I cover a lot of events and have so for several years. That’s why it is a great feeling when you still can get surprised. WROC# was outstanding in every aspect. For a first-time organised event with free tickets and a five figure price tag for the organisers everything went amazingly smooth and you can see the passion and drive of the organisers.
I am humbled and feel very thankful for having been part of this. The way the organisers made me feel welcome and left no question open was exceptional and many conferences can learn from the little tricks they used. The printout with a detailed day-to-day schedule for me was excellent. The “thank you” goodie bag in the room nothing more than overwhelming.
Instead of a speaker dinner the day before the event we went on a tour of the city which was also a scavenger hunt. This allowed us to not only get to know the speakers, but also the organisers and get a feeling of the place and its people before being in a venue for a day and leave as strangers again.
Attendees had exceptional catering, endless drinks, coffee and locally brewed beer for the occasion at the after party. The wireless worked and all talks were live-streamed. There was a table football tournament, arcade machines and a band and many more things to keep people around and make them get to know one another.
All in all this was an amazing conference and I spent the next day at Objectivity to give them feedback and help them with a few of their outreach/developer evangelism questions as I felt just giving my talk and being at the event all day wasn’t enough. It was a superb experience, thanks to all involved!
Current advancements in ECMAScript are a great opportunity, but also a challenge for the web. Whilst adding new, important features we’re also running the danger of breaking backwards compatibility.
These are my notes for a talk I gave at the MunichJS meetup last week. You can see the slides on Slideshare and watch a screencast on YouTube.
There will also be a recording of the talk available once the organisers are done with post-production.
The forgivefulness of JS is what made it the fast growing success it is. It allows people to write quick and dirty things and get a great feeling of accomplishment. It drives a fast-release economy of products. PHP did the same thing server-side when it came out. It is a templating language that grew into a programming language because people used it that way and it was easier to implement than Perl or Java at that time.
As it is with everything that is distributed on the web once, there is no way to get rid of it again. We also can not dictate our users to use a different browser that supports another language or runtime we prefer. The fundamental truth of the web is that the user controls the experience. That’s what makes the web work: you write your code for the Silicon Valley dweller on a 8 core state-of-the-art mobile device with an evergreen and very capable browser on a fast wireless connection and much money to spend. The same code, however, should work for the person who saved up their money to have a half hour in an internet cafe in an emerging country on a Windows XP machine with an old Firefox connected with a very slow and flaky connection. Or the person whose physical condition makes them incapable to see, speak, hear or use a mouse.
Our job is not to tell that person off to keep up with the times and upgrade their hardware. Our job is to use our smarts to write intelligent solutions. Intelligent solutions that test which of their parts can execute and only give those to that person. Web technologies are designed to be flexible and adaptive, and if we don’t understand that, we shouldn’t pretend that we are web developers.
The web is a distributed system of many different consumers. This makes it a very hostile development environment, as you need to prepare for a lot of breakage and unknowns. It also makes it the platform to reach much more people than any – more defined and closed – environment could ever reach. It is also the one that allows the next consumers to get to us. It’s hardware independence means people don’t have to wait for availability of devices. All they need is something that speaks HTTP.
Whilst JS is a great solution to making the web respond more immediately to our users, it is also very different to the other players like markup and style sheets. Both of these are built to be forgiving without stopping execution when encountering an error.
A browser that encounters a unknown element shrugs, doesn’t do anything to it and moves on in the DOM to the next element it does understand and knows what to do with. The HTML5 parser encountering an unclosed element or a wrongly nested element will fix these issues under the hood and move on turning the DOM into an object collection and a visual display.
A CSS parser encountering a line with a syntax error or a selector it doesn’t understand skips that instruction and moves on to the next line. This is why we can use browser-prefixed selectors like – webkit – gradient without having to test if the browser really is WebKit.
When you build a house and the only way to get to the higher floors is a lift, you broke the house when the lift stops working. If you have stairs to also get up there, the house still functions. Of course, people need to put more effort in to get up and it is not as convenient. But it is possible. We even have moving stairs called escalators that give us convenience and a fall-back option. A broken down escalator is a set of stairs.
The simplest way to ensure our scripts work is to test for capabilities of the environment. We can achieve that with a very simple IF statement. By using properties and objects of newer browsers this means we can block out those we don’t want to support any longer. As we created an HTML/Server solution to support those, this is totally acceptable and a very good idea.
The developers in the BBC call this “cutting the mustard” and published a few articles on it. The current test used to not bother old browsers is this:
Recently, Jake Archibald of Google found an even shorter version to use:
This, however, fails to work when we start changing the language itself.
x = 0;
The lenient parser doesn’t care that the variable x wasn’t initiated, it just sees a new x and defines it. If you use strict mode, the browser doesn’t keep as calm about this:
'use strict'; x = 0;
In Firefox’s console you’ll get a “ReferenceError: assignment to undeclared variable x”.
ECMAScript – changing the syntax
There is no progressive enhancement way around this issue, and an opt-in string doesn’t do the job either. In essence, we break backwards compatibility of scripting of the web. This could be not a big issue, if browsers supported ES6, but we’re not quite there yet.
ES6 support and what to do about it
If you want to help with the adoption of ECMAscript in browsers, please contribute to this test suite. This is the one place all of them test against and the better tests we supply, the more reliable our browsers will become.
Ways to use the upcoming ECMAScript right now
If we consider the use cases of ECMAScript, this is not that much of an issue. Many of the problems solved by the new features are either enterprise problems that only pay high dividends when you build huge projects or features needed by upcoming functionality of browsers (like, for example, promises).
The changes mostly mean that JS gets real OO features, is more memory optimised, and that it becomes a more enticing compile target for developers starting in other languages. In other words, targetted at an audience that is not likely to start writing code from scratch in a text editor, but already coming from a build environment or IDE.
Quite some time ago, new languages like TypeScript got introduced that give us the functionality of ECMAScript6 now. Another tool to use is Babel.js, which even has a live editor that allows you to see what your ES6 code gets converted to in order to run in legacy environments.
Return of the type attribute?
One way to ensure that all of us could use the ECMAScript of now and tomorrow safely would be to get browsers to support a type of ‘ES’ or something similar. The question is if that is really worth it seeing the problems ECMAScript is trying to solve.
Update: Axel Rauschmayer proposes something similar for ECMAScript modules. He proposes a MODULE element that gets a SCRIPT with type of module as a fallback for older browsers.
It doesn’t get boring
In any case, this is a good time to chime in when there are discussions about ECMAScript. We need to ensure that we are using new features when they make sense, not because they sound great. The power of the web is that everybody is invited to write code for it. There is no 100% right or wrong.