Yes, sure. I am Andrea Giammarchi, I am a software engineer with Nokia, working mainly in mobile HTML development, right now we are focusing on mobile HTML5 maps applications, API and UI framework component.
In one of these talks I’ve seen this deadline for targets for ECMAScript. It’s really good that between the third version and the current version there is a ten years gap, so that means something because more and more people start using it for almost everything, both client and server, so I would say the language is good enough, is expressive enough but there are little things that are not perfect, I know that even the third version has been created in a really short time so many people have evolved and the ES-Discuss mailing list is open. These guys are all really professional people, most of them are developers, they are coding on daily basis and they are also listening to other developers that are coding on daily basis. So it’s good, there is a lot of progress, I’m lucky enough to work already with version 5, I am really looking forward for version 6, or what’s called "JavaScript.Next".
Yes, it is somehow better, because you don’t have to deal with the old IE inconsistencies, almost every browser is following standards, and at least for the language itself there are really few things that we have to fix, there are only a few glitches. Every now and then we have problems with the code itself, we have more problems with CSS3 to be honest, but from the JavaScript side it changed the way we code, so we all have sort of a background with desktop browsers, and suddenly all those ugly patterns or ugly tricks because of IE, because of this, because of that , they disappear. Also the core library is really thin, it’s a tiny piece of code that just works because a lot of abstractions are not needed anymore so where we can go native and we know there is support, at least for our target platform, we can just use JavaScript as it is and it’s not that bad.
So polyfills now are widely used, which is good, I write polyfills, this GSL was called, if I remember, JavaScript library and the main purpose of this library was to fill the gap already a massive one between IE4, IE5, IE5.5, IE6, this really old browser. That was not that successful at the time, but eventually after all these years developers started understanding that polyfills are really a great thing, is something that you inject. It’s not real dependency, something that you can’t drop as soon as the browser scenario evolves, or as soon as your target browser or your users are not using the browser anymore or they have a newer version, so basically it’s sort of a graceful advancement or what are the JavaScript possibilities, and as soon as no needed it just runs faster, because all the polyfills will go so the page will be smaller and all these wraps are not needed anymore and you don’t have to change anything in your logic, so you just focus, rather than on API change or whatever library, you keep focusing on standards and you just write pure JavaScript. That’s one of the main reasons. Also polyfills are good because they bring already new things that are needed. So the reason, for example I created this ES6 collection or harmony collection, it’s a polyfill to bring map, week map and set as it is right now defined on harmony, wikipage. That’s good because the map for example is something the developers always injected properties or in dominos or they did any sort of sorcery to relate this kind of two different objects without polluting the global object or without polluting the object itself. It was also really easy to create recursion, because the properties were pointing to another object which had the property that this object... So this is something that can be easily solved with map and map is great. So as soon as map will be available natively, it will also be faster and that’s good because it’s fast enough already and today you can already start relating objects without coupling them with each other. So this is one reason and this is really good but the same would be for canvas, was one of the most used polyfills was this ex canvas API, almost 100% of the canvas API in browsers where it was not even standard yet, wasn’t implemented at all. That’s good because whoever used that ex canvas file today it can just drop it, and everything will work and there is no need, it’s simply not needed.
There are two big challenges. First of all, at the very beginning there was performance. We tried to be as small as possible and as fast as possible. That was one thing easy for most modern devices but not completely consistent, so for example we had the very first tablets with the Android 3, I don’t know what was wrong there, but I was surely not harder acceleration or if we were forcing harder acceleration was even lower and it was something weird, so right now at least it looks like we managed to be reasonably fast across all supported platforms which starts from Android 2.2, which is a good achievement. The second thing, the hardest challenge is to really be cross platform, it’s hard, this is something that makes our day surely not boring, never, at all. These are problems we are facing especially with the whole stack, not just the JavaScript, it’s CSS3.
6. You mean performance issue with CSS3 or even support?
Both support and performance because when you try for example to accelerate some layer, on some devices you have completely unexpected behaviors. So you have to be careful, at some point we were thinking we should just drop transitions for this kind of devices because there is no way we can control them, it was completely wild and unpredictable. This is something we fixed right now but we are still thinking how to really bring the same look and feel all over the place, also other browsers, not just the one we are supporting.
I’m not sure, I think CSS3 is good, but I think CSS is taking a weird direction because it’s not in charge of the view, the presentation anymore. There are few new things, like this calc or function invoke, so it’s starting to become what was CSS expression in Internet Explorer a while ago. I thought that was cool, but everybody said don’t use them because they slow down the rendering and you cannot possibly know when these are invoked. I’m not sure if that is true because I’m pretty sure those are invoked every time there was a repaint or reload of the page. So, it’s good to have native power behind CSS3, it’s not that good if you cannot control this power, so still I do not see any facility to understand really what is going on, to be notified about some property or to rely on some behavior. With CSS3 we sometimes had transitions that were supposed to act but never happened or events, web kit transitions, that on some devices it wasn’t fine at all. And sometimes it was. And to make this happen you have to touch the screen at least once, which is kind of weird, it’s about visual stuff, what has the touch to do? So these are the main problems we faced, we keep facing all this time, but we found a few things that are consistent and those are things that we stick with right now, because we do not want to put too much, but we are also investigating about some 3D transition, which look really cool, but they are not widely supported, but let’s see what we can do.
We are using emulators but we know emulators are not that good, so emulators are ok, just the fact that you are using the mouse for the emulator that is already something different. You can simulate in some emulators even multi touch and stuff like this, but in some emulator you cannot and also I think the GPS was sometimes unreliable, so there are a few things that on emulator do not run very well or it looks ok and then on the real device it’s just different, it’s just not working or something is just different, tiny, winy differences that compromise our release. In the team, somebody for example is using Chrome, somebody is using Safari, I personally use WebKit Nightly, I use WebKit Nightly because WebKit is behind all the browsers that we are supporting and I would like to know in advance if something will break at some point, so if they introduce some new feature, I know it’s not the most stable thing, but if they introduce some new feature or something that breaks our logic, our code or even CSS, that’s for me a way to know in advance "Ok, guys, we need to change, to refactor here because this won’t work in the next update for Android or something, or a browser". So the very first test is there because we have all these tools in the browser that we cannot really do anything without those tools. They are essential to monitor, also to profile performance also to check to have the DOM under control or see what’s going on. So the very last step is to deploy to the device and give it a spin. We do, let’s say, continuous integration and we branch every little feature that we would like to release and we test this feature in isolation. So branch per branch and see if everything is fine, then we usually merge with the rest to see that nobody broke somebody else’s code. At that point we have unit test, acceptance test, integration test, functional test, any sort of test, we do all of them, it takes quite a while, but it pays back, because as soon as something is broken we will know and we can quickly fix. So far it has been good, we have been quite fast to bring new features.
So, I like for example JavaScript as it is, I usually don’t use libraries unless it’s really necessary. The tools we need, from our side, for our framework, we code everything we need, there isn’t really much we need, the framework is really tiny, it’s not that difficult to use. So we provide a sort of tool, but the tool is a little abstraction, some utilities just come for any kind of application development. So we are using js-test-driver, which is quite a good one for testing, we use also Cucumber, I think we are using a lot of tools, but those tools are all for testing and keeping an eye on what’s going on and everything should always be green, so it’s more about testing, that’s the place where you need good tools and you want to trust those tools because if your tools say everything is ok but it is not, we have a problem there. That happened a couple of times, sometimes it was our fault, sometimes it was the testing framework fault, when it’s the testing framework’s fault it’s not good, so at that point you have to quickly change into something else. Sometimes it’s not easy because you have to rewrite a lot of code.
So, in all these years of programming, there are really few places where I have been where testing was important. I can understand why, sometimes it’s hard to just set up your environment, you want to test something you have some piece of code you want to do test driven development, that would be the next step. First you have to be sure that something you wrote is working. I’ve seen a lot of times in other teams, not in Nokia, but other teams outside of Nokia in other companies where I have been collaborating or working for, people just write something, they manually test and that’s it, looks like it works, let’s go, it’s done. That manual test it’s like those three or four lines of code that always get lost in the process but those are important, because you are testing because you want to be sure everything is working. So I was thinking, what if I create the most simple way to test whatever it is and you just focus on writing those three lines of codes and save the file and that’s it, you don’t have to remember, you just run the test, it has to be fast and has to be surely JavaScript oriented. And that’s why I created this WRU, which is I think really easy, you assert if there is something asynchronous, you just call async and inside asynchronous the moment you assert, the process behind the sync keeps going. So that’s not much to remember, not much to configure, there is nothing actually to configure. The build system which I updated a few minutes ago, you can rebuild the WRU with a Node.js, before you needed Python; it creates automatically a template so you can have your own template file, it can be HTML if you want to test something in the browser, it can be Console if you want to test on Node.js or if you want to test on Rhino, I recently added the PhantomJS also, which is this headless WebKit version also and there are not many test frameworks that work there. It was fun first of all, it was not such big code so it was just "Ok, let’s see if it works", people look really interested, it’s really easy, it’s really straightforward, so probably it’s not the most complete test framework but it’s good for people that never even did it, that never even wrote a single test, because maybe they think it’s not worth it, they don’t have time, but I believe that any developer at some point, whether to write you have to test that stuff either in Console or somewhere else, so just copy and paste, put it in WRU and forget about this. What results you see is real.
Yes, so I think the code is the same, or at least the core is the same, there is no dome on the server, usually, you can simulate that as well, but also the way you load things is different, you load files, you load dependencies, so Node.js for example has this requirement, which is the only thing that is synchronous, so the moment you require, you really grab the file, evaluate the script, and return whatever is exported in that module or execute whatever it’s executed there. With NodeJS the require logic is full modules, but if you start creating a module for everything and publish to MPM, it’s really easy to lose the hierarchy in your folder. You can require also using the puff, so you have the main route of your project and then you can require dot/fullthe/namespace/module, and this I think helps to keep things under control, so you still have a proper folder hierarchy. Once you have all these distributed files, it’s more or less like having a Java project with a lot of folders a lot of namespaces, everything is in a namespace, you can play with namespace and use namespace as folders. It’s no big deal and it’s something we did similar with another team many years ago, was working in Switzerland, we were using Rhino interface also some piece of Javascript for Rhino, every single JavaScript file was a file apart, it wasn’t this big blob, the big blob, the big container, the big clojure, I think that’s not part of the service at JavaScript, that’s part of some library because you have your own private scope, you want make life easier for mini files, so if you have these private variables that stream quite well, then you want to be able to distribute the library in one single file, classic example is JQuery, the way JQuery built itself, they have the files structure even at the beginning of the clojure and the end of the clojure, these are different files. And they have been working on the library for a while and I think it’s not that bad organized, it’s just they have a build system, a build process there, the same I do usually, in WRU there is a similar concept, once you start, rather than creating 10000 lines of code, you start creating your own piece of file to add a build process that everything together and built a massive clojure. It’s straightforward but still it’s something you do for the web, you don’t do for the server, so on the server just try to be as organized as possible, as any other project.