Might be one of the saddest things I've read linked out of Hacker News. As developers we're doomed to a future of using a awful language because it happened to be at the right place at the right time and was good enough. Now we're stuck with it. Reminds me of DOS.
The author mentioned transpiling other languages to Javascript and Javascript to Lua.
Personally, I much, much prefer working in Clojurescript to Javascript. Once my dev environment is setup, and I am rolling, there is not much inconvenience or build delays at all. My setup is editing in IntelliJ (both Clojure and Clojurescript), one clojure repl, and one lein autobuild task to keep the generated Javascript up to date, given about a one second delay.
Javascript is not such a bad language, I use it directly when doing meteor.js development, but I think the future is better languages like Clojure, Haskell, Scala, etc. transpiling to Javascript.
> Javascript is not such a bad language, I use it directly when doing meteor.js development, but I think the future is better languages like Clojure, Haskell, Scala, etc. transpiling to Javascript.
Honestly I think this has been the 'future' for a long time now, and I still don't see it happening anytime soon. Clojurescript as a language was announced in mid 2011, NodeJS came on the seen in late 2009. Both were languages never or barely used in their respective domains (server vs client side), but NodeJS has clearly had way more adoption on the server side then Clojurescript ever has had on the client.
Unless we get significant browser buy in for other languages (aka not just Chrome) and much better tooling I don't think any transpiled language is ever going to go beyond the minor niches they fill. And I say all this as a huge Scala fanboy, having used it for years in a professional way, and being very interested in ScalaJS. There simply isn't a language that has the buy in and following Javascript has been able to develop.
I can't wait for the time to be able to write in javascript native code to run on Android or iOS. Maybe a future TypeScript would be the solution for this but it is not too late to remind people that transpiling is a two way street.
Great read, but it seems like the article overlooks a few other pretty significant reasons for Javascript's current dominance: (a) jQuery and (b) Apple keeping Flash out of iOS made from the start.
Say what you will about the relative inelegance of jQuery, at the time of its release it certainly made JS--particularly DOM manipulation and AJAX--very accessible and cross-browser compliant. It definitely made articles like this seem quaint. [1][2]
At about the time of jQuery's release, Flash development was a viable alternative for smaller sites. I was doing bits and pieces of freelance around 2007 and after the iPhone came out, even my least tech-saavy clients stopped talking about Flash.
Pretty sure that these two bits made it so that every front end dev/ designer in the world was at least passably decent at Javascript by the time Node arrived.
As for jQuery - nobody disputes that it had HUGE impact on the web - document.querySelector(All) itself is the living proof to that claim. It's just... it was around for waaay to long.
Building tools and extending what is currently made available to developers by the platform - all this is in our very natures as developers. We did that even in the early days, when low-level primitives were mostly missing to support us in that work.
Jake Archibald explains this in a comment on Nat Duca's post over at G+[1] - give developers some primitives; see what they do with them - then distill it and create high-performance features out of what now you already know there is a market for. TC39 works on this basic principle (everybody whines about types in JavaScript - TypeScript might be the JavaScript's jQuery here, paving the way for some distilled type system in JS (or SoundScript. or anything else that's out there).
*
As for Apple - I am siding with Peter-Paul Koch on this[2] - Apple had some quite a few good deeds in favor of the web, but that was a long time ago. Nowadays it just seems to be protecting its walled garden that is native apps & the related ecosystem - certainly not giving a whole lot about making the web a better place (or devs, for that matter). The Pointer Events fiasco is a perfect reminder to all this.
For any good Apple has did to the web, the surely made equal bad so the scales are (IMHO, at most) 50-50 here.
> JavaScript just happened to be a nice fit to evented, non-blocking I/O, and a single-threaded event-loop based environment.
I keep seeing variations on this statement, and I have never figured it out. What, exactly, is it about JavaScript that makes it particularly appropriate for this paradigm?
The way I see it, the only abstraction JS provides that helps with this is first class functions, which are also present (and often richer and more robust) in many other languages.
Not just first class functions -- anonymous functions, and closures.
Python has first class functions, but not anonymous functions, since lambdas aren't full functions.
And Python doesn't have closures, because you have to use "global" or "nonlocal" (in Python 3) to assign a a variable in an enclosing scope.
These features let you write concurrent state machines in JS without explicit state -- you basically use the stack as state.
Python was pretty early in terms of event loop programming for interpreted languages -- asyncore in the stdlib, and Twisted. But I agree that the node.js style is nicer than asyncore, Twisted, or Tornado. I prefer coroutines over state machines, but if you're going to write state machines, than doing it with anonymous closures is nicer than doing it "manually" with classes and so forth.
Tcl was even earlier, but Tcl is pretty foreign to most people, and was more of an embedded language than a scripting language. Pretty sure Tcl has full anonymous closures, but it is a bizarre language in some other ways.
I haven't seen the event loop style in Perl but I think you can do it. If someone has an example I'd like to see it. To me, Perl only barely qualified as a real programming language because you can't even name your function params? At least when I used it, which was over 10 years ago.
JS isn't even particularly good at evented, non-blocking I/O: chains of asynchronous calls become series of ever-more-indented function(){}s. Languages with coroutines (Lua) or first-class continuations (Scheme) can chain asynchronous calls in a more straightforward style.
> What, exactly, is it about JavaScript that makes it particularly appropriate for this paradigm?
V8.
And it's a pretty powerful language. C-like syntax (familiar), Lisp-like (powerful/flexible), it's everywhere and it's fast (thanks to V8). Really, if it weren't for Chrome, Node.js wouldn't be a thing, and JavaScript wouldn't be ruling the world.
Almost every popular programing environment provides an incredibly unsound shared-memory multithreading library in the distribution, which winds up being heavily used by every other library--even sometimes built-in ones. Javascript in both the browser and not refrains from this, making it generally safe to use not-invented-here code.
In other languages, you could use libuv or tornado or aio or whatever, but it's like throwing away the entire ecosystem and using an obscure language anyway.
"What, exactly, is it about JavaScript that makes it particularly appropriate for this paradigm?"
Devs with experience writing interactions with the DOM had already convinced themselves that callbacks nested ten deep was a totes OK way to write code, "releasing Zalgo" and all.
In JS, you know that library code that you call almost certainly won't do blocking I/O.
If you're trying to do non-blocking async stuff in other languages, you have to hope/check that none of your code and none of your dependencies try to do blocking I/O. (Unless you're using something that does async under the covers like haskell or go)
JS is in every web browser. thats why. number one. period. because there are plenty of other language syntaxes compatible with non-blocking mono-threaded EDA.
JavaScript is popular because browser vendors have not yet agreed on anything better. Remember Native Client? You might as well forget it -- Mozilla didn't sign on. ActiveX is a joke, but if Mozilla & Google et al had moved more confidently towards something Native Client-ish, we could be writing web apps in Go/Rust instead of JS. (or Groovy, $lang_of_choice) But what's their incentive to make that effort?
Ajax was great when IE rolled it out all by themselves. It first might seem like a skunkworks like ActiveX if you didn't know better. Give it a few years' time, coordination and cooperation, and now we've got a Websockets RFC. Consensus takes time.
As crusty as JS may be, I don't think these are dark times at all. I think the rate of evolution (in JS engines, ES6/7, ..) is so swift it's more worthwhile to stick to the JS platform than to reinvent the web yourself.
What's ironic is that Mozilla is deeply infused with its own version of ActiveX called "XP/COM" that's practically the same thing (to a point), just using a totally different set of (open source) tools.
You can use and implement COM or XP/COM components in C, C++, JavaScript and (theoretically but not commonly for XP/COM) other languages. XP/COM is not syntactically compatible with COM, and uses a completely different headers, tools, etc, but they're identical in memory layout and behavior and design. Of course beyond identical IUnknowns, XP/COM's interfaces, metadata, and JavaScript interoperability are totally different than ActiveX on IE.
They eventually realized they'd gone too far with it, and went through a "de-COMification" phase around 2002, and it's been a few years since I worked on a xulrunner application, but as far as I know, XP/COM is still pervasive throughout Mozilla/Firefox/xulrunner, including its deep internals and its chrome user interface layer.
COM was a good solution for a particular set of problems at the time, which Mozilla also needed to solve, so XP/COM made sense in that context. But these days, it makes more sense to use JavaScript and JSON directly as the interoperability layer between components and other languages, instead of COM.
JavaScript won the language war, so it gets the privilege of being the "linguistic motherboard" that you can plug other languages, emulators and components into.
> we could be writing web apps in Go/Rust instead of JS. (or Groovy, $lang_of_choice)
Couldn't work out if you're using Groovy as an example of a shoddy language used because there was nothing better (like JS), or a better language that everyone couldn't agree on (like Go/Rust). Groovy was originally based on Beanshell but with closures added, and became mildly popular for scripting on the JVM around 2006 onwards, and its later use by Gradle for 30-line build scripts. A meta-object protocol was added and Grails (a knock-off of Rails) was built to utilize it, though Grails use is on the decline partly thanks to Node.js. Although the backers of Groovy have since added other cruft, it hasn't moved beyond its original use case of scripting the JVM (like Bash for Linux).
There's plenty of interesting historical facts here, but they're interspersed with an emptier and rather sensationalistic writing style that seems to overemphasize the novelty of the various solutions listed. More importantly, the post doesn't seem to answer the question that it poses at the beginning - "It’s not too long until your very toaster will be running JavaScript… but why?" The only answer I got out of it was "Because."
I find the implication in the Moore's law section about performance to be a bit unfortunate. Ideas like this only strengthen Wirth's law. We're talking about plain old JavaScript here, after all, not some hypothetical Smalltalk/Erlang hybrid language with mystic productivity benefits or anything like that.
The impact on front-end development in the last three years has been undeniable.
Even now, you're either a Javascript Developer or you're a designer (a designer with HTML/CSS chops but really weak Js skills), the role of the front-end dev has morphed seemingly morphed into this two for some reason.
Rebecca Murphey also said this today but in my experience I'm not really seeing it. Just checked job listings now and all front end positions heavily promote HTML and CSS with minor exceptions for more JS heavy roles. More telling is a lack of non-JS roles i.e. I'm certainly not seeing any "HTML/CSS developer" positions open.
What I thought to be the most promising part of the article:
Tessel created "a compiler that translated the JavaScript source to Lua and executed the translated code on the very compact Lua virtual machine on the microprocessor of the device".
The newer tessel is actually abandoning this model in favor of a faster system that just runs actual node/iojs and modules built for the platform architecture.
As javascript lover I should admit that I think this is not about about javascript as language, It is more about being in right time and right place.Every one here knows javascript is awful language for optimizing and V8 kind of blow it up with every kind of optimization most of us cannot even imagine.Imagine instead of javascript , Python/Lua was standard way of browser to make dynamic content in ~2000 and web explosion days.Then I think we would talk about that language instead of javascript today.When you looking at big picture , you can see google push's Dart , which they somehow (at least I think) plan to replace javascript with Dart (I am not telling it is going to be that way , But I think this is how they have plan to do in long-term future)
UPDATE : just a day after this comment , Google announced it will not integrate dart to its browser and it will only focus on dart2js. So , I was Wrong google long term plan.
Wow. Lots of information there, lots of things I didn't know about!
Part of me is appalled that a language as icky as Javascript is taking over the world like this. But I'm happy that any language at all is giving us this level of flexibility and standardization.
Javascript is definitely an interesting language. For a while there it was the lament of code purists who shrieked every time you called it a language with the usual retorts like, "Javascript isn't a language, it's a hack"
I think ECMAScript 6 is definitely a welcome change to the language, ES7 will be undeniably better (even if for Object.observe alone). Now that releases for ECMAScript specifications will be released yearly, we'll see the language evolve and now that we have a nice range of evergreen browsers, developers can take solace in the fact they don't have to support older browsers for much longer (as new features are released, browsers incorporate them).
While Javascript definitely has its warts, what other language can boast of the same market share as Javascript? There is no such thing as a perfect language. Not to mention its low barrier to entry, nothing to deploy, no compiler to configure and how powerful it is in capable hands. I think the success of Javascript was more than being in the right place at the right time, I think its ease of use spurred a booming community. Not to mention the fact you could be confident you can write Javascript and it'll run basically anywhere.
People who feel the need to complain about how bad Javascript is to educate themselves further or most likely have never used it properly. There are definitely bad parts in Javascript, but any decent developer who has a good understanding of Javascript knows what those bad parts are and how to avoid ever encountering them. Any language allows you to write poor code, some just make it easier than others (like PHP).
For me the biggest and most exciting thing to happen to Javascript is React.js. And once it is released if my gut-feeling is correct: React Native is going to drive the Javascript language even further, possibly spurring a JS revolution even more-so than Node.js/IO.js has.
Really great read... I used to write a lot of JScript in classic ASP, as well as the MS script runtime in windows... I think the only really ugly part was when you had to deal with COM enumerations. I also used to use hidden frames as post targets and use JSONP-like callbacks into request queues... most often I'd use the ADO option which allows for a response to be serialized into a string specifying a field and row delimiter.. I'd have my client-side script split this out. I also remember it being much faster early on to fully re-render a frame vs. manipulating the DOM for a lot of things. DHTML while supporting NN4/IE4 was a pain.
I couldn't be happier for where JS has come.. I use node's tooling daily, and although I do use BabelJS for ES6 features, I find it to be a very good fit (with more functional thinking) for a lot of problems.
undefined !== null ( but native operators like ? and if uses == and not === )
I'm really glad Javascript is taking over. Mostly because I am a small business / indie dev and using Javascript allows me to off-load a lot of work onto distributed client computers. Which, in turn, allows me to piggy back off of Google, Github, etc., for free hosting and be massively "scalable" to traffic spikes with no cost to me. Js has become massively portable so rapid prototyping and deliver is more possible now than ever.
[+] [-] cognivore|11 years ago|reply
[+] [-] mark_l_watson|11 years ago|reply
Personally, I much, much prefer working in Clojurescript to Javascript. Once my dev environment is setup, and I am rolling, there is not much inconvenience or build delays at all. My setup is editing in IntelliJ (both Clojure and Clojurescript), one clojure repl, and one lein autobuild task to keep the generated Javascript up to date, given about a one second delay.
Javascript is not such a bad language, I use it directly when doing meteor.js development, but I think the future is better languages like Clojure, Haskell, Scala, etc. transpiling to Javascript.
All that said, that was a nice article!
[+] [-] efuquen|11 years ago|reply
Honestly I think this has been the 'future' for a long time now, and I still don't see it happening anytime soon. Clojurescript as a language was announced in mid 2011, NodeJS came on the seen in late 2009. Both were languages never or barely used in their respective domains (server vs client side), but NodeJS has clearly had way more adoption on the server side then Clojurescript ever has had on the client.
Unless we get significant browser buy in for other languages (aka not just Chrome) and much better tooling I don't think any transpiled language is ever going to go beyond the minor niches they fill. And I say all this as a huge Scala fanboy, having used it for years in a professional way, and being very interested in ScalaJS. There simply isn't a language that has the buy in and following Javascript has been able to develop.
[+] [-] rjbwork|11 years ago|reply
[+] [-] timepiece|11 years ago|reply
[+] [-] chondle|11 years ago|reply
Say what you will about the relative inelegance of jQuery, at the time of its release it certainly made JS--particularly DOM manipulation and AJAX--very accessible and cross-browser compliant. It definitely made articles like this seem quaint. [1][2]
At about the time of jQuery's release, Flash development was a viable alternative for smaller sites. I was doing bits and pieces of freelance around 2007 and after the iPhone came out, even my least tech-saavy clients stopped talking about Flash.
Pretty sure that these two bits made it so that every front end dev/ designer in the world was at least passably decent at Javascript by the time Node arrived.
[1] http://boxesandarrows.com/htmls-time-is-over-lets-move-on/ [2] Also, Mootools and Prototype and YUI etc, but jQuery is the one that became ubiquitous
[+] [-] flaki|11 years ago|reply
Building tools and extending what is currently made available to developers by the platform - all this is in our very natures as developers. We did that even in the early days, when low-level primitives were mostly missing to support us in that work.
Jake Archibald explains this in a comment on Nat Duca's post over at G+[1] - give developers some primitives; see what they do with them - then distill it and create high-performance features out of what now you already know there is a market for. TC39 works on this basic principle (everybody whines about types in JavaScript - TypeScript might be the JavaScript's jQuery here, paving the way for some distilled type system in JS (or SoundScript. or anything else that's out there).
*
As for Apple - I am siding with Peter-Paul Koch on this[2] - Apple had some quite a few good deeds in favor of the web, but that was a long time ago. Nowadays it just seems to be protecting its walled garden that is native apps & the related ecosystem - certainly not giving a whole lot about making the web a better place (or devs, for that matter). The Pointer Events fiasco is a perfect reminder to all this.
For any good Apple has did to the web, the surely made equal bad so the scales are (IMHO, at most) 50-50 here.
[1]: https://plus.google.com/u/0/+NatDuca/posts/De8Bv6F4fyB
[2]: http://www.quirksmode.org/blog/archives/2015/02/tired_of_saf...
[+] [-] pdpi|11 years ago|reply
I keep seeing variations on this statement, and I have never figured it out. What, exactly, is it about JavaScript that makes it particularly appropriate for this paradigm?
The way I see it, the only abstraction JS provides that helps with this is first class functions, which are also present (and often richer and more robust) in many other languages.
[+] [-] chubot|11 years ago|reply
Python has first class functions, but not anonymous functions, since lambdas aren't full functions.
And Python doesn't have closures, because you have to use "global" or "nonlocal" (in Python 3) to assign a a variable in an enclosing scope.
These features let you write concurrent state machines in JS without explicit state -- you basically use the stack as state.
Python was pretty early in terms of event loop programming for interpreted languages -- asyncore in the stdlib, and Twisted. But I agree that the node.js style is nicer than asyncore, Twisted, or Tornado. I prefer coroutines over state machines, but if you're going to write state machines, than doing it with anonymous closures is nicer than doing it "manually" with classes and so forth.
Tcl was even earlier, but Tcl is pretty foreign to most people, and was more of an embedded language than a scripting language. Pretty sure Tcl has full anonymous closures, but it is a bizarre language in some other ways.
I haven't seen the event loop style in Perl but I think you can do it. If someone has an example I'd like to see it. To me, Perl only barely qualified as a real programming language because you can't even name your function params? At least when I used it, which was over 10 years ago.
[+] [-] nissimk|11 years ago|reply
[+] [-] panic|11 years ago|reply
[+] [-] Mikeb85|11 years ago|reply
V8.
And it's a pretty powerful language. C-like syntax (familiar), Lisp-like (powerful/flexible), it's everywhere and it's fast (thanks to V8). Really, if it weren't for Chrome, Node.js wouldn't be a thing, and JavaScript wouldn't be ruling the world.
[+] [-] bcoates|11 years ago|reply
In other languages, you could use libuv or tornado or aio or whatever, but it's like throwing away the entire ecosystem and using an obscure language anyway.
[+] [-] al2o3cr|11 years ago|reply
Devs with experience writing interactions with the DOM had already convinced themselves that callbacks nested ten deep was a totes OK way to write code, "releasing Zalgo" and all.
[+] [-] surrealize|11 years ago|reply
If you're trying to do non-blocking async stuff in other languages, you have to hope/check that none of your code and none of your dependencies try to do blocking I/O. (Unless you're using something that does async under the covers like haskell or go)
[+] [-] mkramlich|11 years ago|reply
[+] [-] arh68|11 years ago|reply
Ajax was great when IE rolled it out all by themselves. It first might seem like a skunkworks like ActiveX if you didn't know better. Give it a few years' time, coordination and cooperation, and now we've got a Websockets RFC. Consensus takes time.
As crusty as JS may be, I don't think these are dark times at all. I think the rate of evolution (in JS engines, ES6/7, ..) is so swift it's more worthwhile to stick to the JS platform than to reinvent the web yourself.
[+] [-] DonHopkins|11 years ago|reply
You can use and implement COM or XP/COM components in C, C++, JavaScript and (theoretically but not commonly for XP/COM) other languages. XP/COM is not syntactically compatible with COM, and uses a completely different headers, tools, etc, but they're identical in memory layout and behavior and design. Of course beyond identical IUnknowns, XP/COM's interfaces, metadata, and JavaScript interoperability are totally different than ActiveX on IE.
They eventually realized they'd gone too far with it, and went through a "de-COMification" phase around 2002, and it's been a few years since I worked on a xulrunner application, but as far as I know, XP/COM is still pervasive throughout Mozilla/Firefox/xulrunner, including its deep internals and its chrome user interface layer.
COM was a good solution for a particular set of problems at the time, which Mozilla also needed to solve, so XP/COM made sense in that context. But these days, it makes more sense to use JavaScript and JSON directly as the interoperability layer between components and other languages, instead of COM.
JavaScript won the language war, so it gets the privilege of being the "linguistic motherboard" that you can plug other languages, emulators and components into.
[+] [-] vorg|11 years ago|reply
Couldn't work out if you're using Groovy as an example of a shoddy language used because there was nothing better (like JS), or a better language that everyone couldn't agree on (like Go/Rust). Groovy was originally based on Beanshell but with closures added, and became mildly popular for scripting on the JVM around 2006 onwards, and its later use by Gradle for 30-line build scripts. A meta-object protocol was added and Grails (a knock-off of Rails) was built to utilize it, though Grails use is on the decline partly thanks to Node.js. Although the backers of Groovy have since added other cruft, it hasn't moved beyond its original use case of scripting the JVM (like Bash for Linux).
[+] [-] vezzy-fnord|11 years ago|reply
I find the implication in the Moore's law section about performance to be a bit unfortunate. Ideas like this only strengthen Wirth's law. We're talking about plain old JavaScript here, after all, not some hypothetical Smalltalk/Erlang hybrid language with mystic productivity benefits or anything like that.
[+] [-] at-fates-hands|11 years ago|reply
Even now, you're either a Javascript Developer or you're a designer (a designer with HTML/CSS chops but really weak Js skills), the role of the front-end dev has morphed seemingly morphed into this two for some reason.
[+] [-] cozuya|11 years ago|reply
[+] [-] linkregister|11 years ago|reply
Tessel created "a compiler that translated the JavaScript source to Lua and executed the translated code on the very compact Lua virtual machine on the microprocessor of the device".
linked: https://tessel.io/blog/98257815497/how-tessel-works-the-basi...
[+] [-] tracker1|11 years ago|reply
[+] [-] findjashua|11 years ago|reply
[+] [-] 0xFFC|11 years ago|reply
[+] [-] 0xFFC|11 years ago|reply
[+] [-] beat|11 years ago|reply
Part of me is appalled that a language as icky as Javascript is taking over the world like this. But I'm happy that any language at all is giving us this level of flexibility and standardization.
[+] [-] DigitalSea|11 years ago|reply
I think ECMAScript 6 is definitely a welcome change to the language, ES7 will be undeniably better (even if for Object.observe alone). Now that releases for ECMAScript specifications will be released yearly, we'll see the language evolve and now that we have a nice range of evergreen browsers, developers can take solace in the fact they don't have to support older browsers for much longer (as new features are released, browsers incorporate them).
While Javascript definitely has its warts, what other language can boast of the same market share as Javascript? There is no such thing as a perfect language. Not to mention its low barrier to entry, nothing to deploy, no compiler to configure and how powerful it is in capable hands. I think the success of Javascript was more than being in the right place at the right time, I think its ease of use spurred a booming community. Not to mention the fact you could be confident you can write Javascript and it'll run basically anywhere.
People who feel the need to complain about how bad Javascript is to educate themselves further or most likely have never used it properly. There are definitely bad parts in Javascript, but any decent developer who has a good understanding of Javascript knows what those bad parts are and how to avoid ever encountering them. Any language allows you to write poor code, some just make it easier than others (like PHP).
For me the biggest and most exciting thing to happen to Javascript is React.js. And once it is released if my gut-feeling is correct: React Native is going to drive the Javascript language even further, possibly spurring a JS revolution even more-so than Node.js/IO.js has.
[+] [-] smrtinsert|11 years ago|reply
Can't wait till the next big one, because this one isn't doing it for me.
[+] [-] tracker1|11 years ago|reply
I couldn't be happier for where JS has come.. I use node's tooling daily, and although I do use BabelJS for ES6 features, I find it to be a very good fit (with more functional thinking) for a lot of problems.
[+] [-] ffn|11 years ago|reply
1 + "2" = "12" but "1" - 1 = 0
0 == false ( "if window.scrollTop ..." will occasionally break on user scroll )
undefined == null ( why do we need 2 empty sets? )
undefined + "dog" != null + "dog" ( breaks transitive property )
undefined !== null ( but native operators like ? and if uses == and not === )
I'm really glad Javascript is taking over. Mostly because I am a small business / indie dev and using Javascript allows me to off-load a lot of work onto distributed client computers. Which, in turn, allows me to piggy back off of Google, Github, etc., for free hosting and be massively "scalable" to traffic spikes with no cost to me. Js has become massively portable so rapid prototyping and deliver is more possible now than ever.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] marchelzo|11 years ago|reply
[+] [-] timepiece|11 years ago|reply
Seriously, what answer were you expecting other than this?
I'm really curious!
[+] [-] ForHackernews|11 years ago|reply
[+] [-] tambourine_man|11 years ago|reply
Maybe you meant Blink, WebKit uses JavaScriptCore
[+] [-] flaki|11 years ago|reply
[+] [-] elchief|11 years ago|reply
[+] [-] aikah|11 years ago|reply
[+] [-] ossreality|11 years ago|reply
[deleted]