March 7, 2016 § 8 Comments
I remember a time, not so very long ago, when Gecko powered 4 or 5 non-Mozilla browsers, some of them on exotic platforms, as well as GPS devices, wysiwyg editors, geographic platforms, email clients, image editors, eBook readers, documentation browsers, the UX of virus scanners, etc, as well as a host of innovative and exotic add-ons. In these days, Gecko was considered, among other things, one of the best cross-platform development toolkits available.
The year is now 2016 and, if you look around, you’ll be hard-pressed to find Gecko used outside of Firefoxen (alright, and Thunderbird and Bluegriffon). Did Google or Apple or Microsoft do that? Not at all. I don’t know how many in the Mozilla community remember this, but this was part of a Mozilla strategy. In this post, I’d like to discuss this strategy, its rationale, and the lessons that we may draw from it.
February 20, 2013 § Leave a comment
« Webkit is a rust bucket. We can’t move away from it, because our users rely on its bugs as much as on its features, but it’s based on deprecated technologies, concepts that don’t scale anymore, and it just won’t match today’s needs or hardware. If we had any choice, we would dump the whole thing and restart from scratch. »
October 13, 2011 § 4 Comments
A few weeks ago, the browser and web development communities started wondering about this mysterious new web language that Google was about to unveil: Dart. Part of the interrogation was technical – what would that language look like? how would a new language justify its existence? what problems would it solve? – and part was more strategic – what was Google doing preparing a web language in secret? where the leaked memos that seemed to imply a web-standards-breaking stance something that Google would indeed pursue? was Google trying to solve web-related problems, Google-related problems or Oracle-related problems?
Now, Google has unveiled the specifications of Dart, as well as library documentation. Neither will be sufficient to answer all questions, but they give us an opportunity to look at some of the technical sides of the problem. As a programming language researcher/designer and a member of the web browser community, I just had to spend some quality time with the Dart specifications.
So, how’s Dart? Well, let’s look at it.
What Dart is
Dart is a programming language and a Virtual Machine. As a programming language, Dart positions itself somewhere in the scope between scripting/web development and application development. From the world of application development, Dart brings
- clean concurrency primitives that would feel at home in Scala, Clojure or Erlang – including a level of concurrent error reporting;
- a clean module mechanism, including a notion of privacy;
- a type system offering genericity, interfaces and classes;
- compilation and a virtual machine;
- a library of data structures;
- no eval();
- data structures that do not change shape with time.
From the world of scripting/web development, Dart brings:
- usability in any standards-compliant browser, without any plug-in (although it will work better in a plug-in and/or in Chrome);
- DOM access;
- emphasis on fast start-up;
- a liberal approach to typing (i.e. types are optional and the type system is incorrect, according to the specifications);
- dynamic errors;
- closures (which are actually not scripting/web development related, but until Java 8 lands or until Scala, F# or Haskell gain popularity, most developers will believe that they are).
Where Dart might help
Web development has a number of big problems. I have
trolled written about some of them in previous posts, and Dart was definitely designed to help, at least a little.
Safety and Code Hygiene
Where Dart might hinder
The single biggest problem with Dart is, of course, its source. To get the VM in the browsers, Google will have to convince both developers and other browser vendors to either reimplement the VM by themselves or use a Google-issued VM. This is possible, but this will be difficult for Google.
The vendor controlled vehicle will be to integrate the VM in Chrome and Android and encourage developers targeting the Chrome Market and Android Market to use Dart. Some speculate that this is a manner for Google to get rid of the Java dependency on the Android Market. In this case, of course, there will be little competition.
Libraries and documentation
Doing it without Dart
Also, while classes and private fields are probably the least surprising techniques for application developers coming to the web, developers used to dynamic or functional languages know that closures and prototypes are essentially equivalent. So, this is essentially a matter of taste.
Isolates are nice. Workers are nice. Isolates are a little easier to set-up, so I would like to see an Isolate-like API for Workers. Other than that, they are essentially equivalent.
String interpolations are nice to have, but not really life-altering. If necessary, they can trivially be implemented by a pre-processor. CoffeeScript might already do it, I’m not sure. Adding this to the JS standard might be tricky, for reasons of backwards compatibility, but there is not much to it.
If we consider I my opinion, there are three ways that Google can get Dart adopted on the web:
- make it the default choice for Android & Chrome development;
- provide a set of killer libraries for the web, that work on all browsers but are truly usable only with Dart (DirectX anyone? something Cocoa-style, perhaps?);
- spend Google-sized budgets on adoption (PR, marketing, GSoC, open-source projects, etc.).
January 26, 2008 § Leave a comment
La communauté OCaml vient de gagner un lieu de discussion pour les recommandations sur la standardisation.
Pour ceux qui sont intéressés, rendez-vous sur le wiki de l’Alliance OCaml.
Des projets sont aussi en train de se mettre en place pour un prochain Summer of Code. Si vous avez des sujets à suggérer, rendez-vous sur la page correspondante.