24 ms·

JavaScript's world domination

295 points by janjongboom 12y ago

mark_l_watson 12y ago
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. All that said, that was a nice article!
- timepiece 12y ago
  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.
  - gcp 12y ago
    What does "native code" mean in that sentence?
    - timepiece 12y ago
      iOS and Android native dev environment
      - rpcope1 12y ago
        Is your Javascript VM not already in native code when you're running Javascript on these platforms? Or are you suggesting that the instruction set for the chips on these devices "be pure javascript"?
        timepiece 12y ago
        That's what I meant by native development in iOS/Android javascript-to-java and javascript-to-obj-c transpiling I'm fully aware of the existense of alternatives out there like PhoneGap, Ionic ..etc but I'm envisioning a future where you could write in javascript mostly everything you could do in other languages and transpilers take care of the rest.
        Nitramp 12y ago
        Both of those platforms have perfectly reasonable languages available (Java & Swift or ObjC), why would you use JavaScript over them? Cross platform UI has AFAICT never worked, so you won't be able to reuse code from one platform on another, or is that what you intend to do? In that case you could still transpile from either Java or Swift...
        timepiece 12y ago
        Because I detest Java and I find it to be archaic, old-fashioned and clunky but that's just me.
        clay_to_n 12y ago
        Sounds like React Native!
        timepiece 12y ago
        but RN at the moment claims to support only iOS So they're half way in their make believe
- efuquen 12y ago
  > 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.
- rjbwork 12y ago
  Don't forget about F#! WebSharper is shaping up to be a pretty nifty project.
findjashua 12y ago
I think if React Native lives up to its promise, it's going to drive a much bigger adoption than node/iojs has.
ttty 12y ago
I've been saying this for years (: happy to hear
beat 12y ago
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.
cognivore 12y ago
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.
- VieElm 12y ago
  EcmaScript 6 and 7 are actually adding beautiful language features. JavaScript is changing in a big way, a lot of new JavaScript will not even resemble the stuff you're probably referring to.
  - angersock 12y ago
    Bug not feature, unfortunately. Were only that effort spent on eradicating the old legacy libraries!
    - flaki 12y ago
      If you are saying this, you certainly didn't read the article (properly). You can not "eradicate old legacy libraries" on whim - this stuff is out there. It is used by software out there. Software that would break if things like that would be removed. You can't just rip out and change parts of it at whim. You have to work around problems - at least until they wane in popularity and slowly die out. Evolution, rather then revolution - as stated in the article. That is exactly what TC39 is doing when they are improving on the standard and JavaScript itself. Case in point: Array.prototype.values was a proposed feature - returning an iterator for the values in an array[1]. The feature was introduced and had to be backed out at least twice[2] because widely used web frameworks (in this case, Sencha) used the attribute "values" on arrays and webapps broke as the method was added to the Array prototype. And this wasn't the first case. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/values https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]: https://esdiscuss.org/topic/array-prototype-values-breaks-the-web https://esdiscuss.org/topic/array-prototype-values-breaks-th...
at-fates-hands 12y ago
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.
- cozuya 12y ago
  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.
ffn 12y ago
As much as I am anally pained by the following things in JS: 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.
- marchelzo 12y ago
  What do you mean by "native operators like ? and if uses == and not ==="?
  - osconfused 12y ago
    I believe ffn is referring to the ternary operators [1] not using identity operator, but rather the equality operator. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons http://stackoverflow.com/questions/359494/does-it-matter-whi...
- timepiece 12y ago
  "1" - 1 = 0 Seriously, what answer were you expecting other than this? I'm really curious!
  - rpcope1 12y ago
    48 might have been a much more reasonably sane answer, or just disallow operations that don't really make any sense, instead of implicitly casting in non-obvious ways.
vezzy-fnord 12y ago
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.
pdpi 12y ago
> 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.
- panic 12y 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.
  - taurath 12y ago
    There are dozens of very decent ways to handle flow control with JS - any time you see indented function chains it tells you this might be poor quality code. For better or worse you can choose a library or write your own - Async.JS, Promises, etc all deal with this. Some abstractions like Async.Auto handle branching paths (series -> parallel -> series) very elegantly.
    - meric 12y ago
      With coroutines in Lua, you could write: function handleRequest(req) data = db.fetch("user") return render("template.html", {user=data}) And if db.fetch and render (both made up functions) are written using the coroutine paradigm, your code would automatically be evented and non-blocking, no need to use libraries to handle your callbacks, and your code has the same style it does if it were blocking. In db.fetch it uses the "yield" keyword that would tell Lua it is about to do an async operation it should wait till it finish before continue running Lua code, meanwhile run something else instead, making it non-blocking and you can run many of these Lua programs at once on a single thread, all of them concurrently.
ossreality 12y ago
I'm sorry, I'm just laughing my ass off. Installed atom-editor last night. Took for god damn ever to install and the install size was hundreds and hundreds of megabytes. It's a damn joke.
linkregister 12y ago
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". linked: https://tessel.io/blog/98257815497/how-tessel-works-the-basics https://tessel.io/blog/98257815497/how-tessel-works-the-basi...
- tracker1 12y ago
  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.
malthaus 12y ago
Ah - the pain of path dependence
ForHackernews 12y ago
Reminds me a bit of this talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
DigitalSea 12y ago
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.
0xFFC 12y ago
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)
- 0xFFC 12y ago
  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.
chondle 12y ago
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. [1] http://boxesandarrows.com/htmls-time-is-over-lets-move-on/ 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 12y ago
  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. [1]: https://plus.google.com/u/0/+NatDuca/posts/De8Bv6F4fyB https://plus.google.com/u/0/+NatDuca/posts/De8Bv6F4fyB [2]: http://www.quirksmode.org/blog/archives/2015/02/tired_of_safari.html http://www.quirksmode.org/blog/archives/2015/02/tired_of_saf...
tambourine_man 12y ago
…since both Webkit and node.js used V8 as their JavaScript engine… Maybe you meant Blink, WebKit uses JavaScriptCore
- flaki 12y ago
  Chromium, rather than Webkit, but yes - thanks for pointing that out I have fixed this (Blink was created much later, in early 2013).
bricss 12y ago
Yeah, JavaScript rocks!
elchief 12y ago
And don't forget to write your Postgres stored functions in JavaScript with PLV8
smrtinsert 12y ago
Blind luck. Web developers had copied and pasted functions for years, a few of them grew up from that basic beginning and tried to make lemonade. Can't wait till the next big one, because this one isn't doing it for me.
aikah 12y ago
wether one likes javascript or not,this is a good article one must read about the state of javascript today.
tracker1 12y ago
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.
mahouse 12y ago
Stop trying to make Firefox OS happen.
arh68 12y ago
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.
- vorg 12y ago
  > 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).
- DonHopkins 12y ago
  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.

295 points by janjongboom 12y ago

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. All that said, that was a nice article!

timepiece 12y ago
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.
- gcp 12y ago
  What does "native code" mean in that sentence?
  - timepiece 12y ago
    iOS and Android native dev environment
    - rpcope1 12y ago
      Is your Javascript VM not already in native code when you're running Javascript on these platforms? Or are you suggesting that the instruction set for the chips on these devices "be pure javascript"?
      - timepiece 12y ago
        That's what I meant by native development in iOS/Android javascript-to-java and javascript-to-obj-c transpiling I'm fully aware of the existense of alternatives out there like PhoneGap, Ionic ..etc but I'm envisioning a future where you could write in javascript mostly everything you could do in other languages and transpilers take care of the rest.
        Nitramp 12y ago
        Both of those platforms have perfectly reasonable languages available (Java & Swift or ObjC), why would you use JavaScript over them? Cross platform UI has AFAICT never worked, so you won't be able to reuse code from one platform on another, or is that what you intend to do? In that case you could still transpile from either Java or Swift...
        timepiece 12y ago
        Because I detest Java and I find it to be archaic, old-fashioned and clunky but that's just me.
        clay_to_n 12y ago
        Sounds like React Native!
        timepiece 12y ago
        but RN at the moment claims to support only iOS So they're half way in their make believe
efuquen 12y ago
> 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.
rjbwork 12y ago
Don't forget about F#! WebSharper is shaping up to be a pretty nifty project.

findjashua 12y ago

I think if React Native lives up to its promise, it's going to drive a much bigger adoption than node/iojs has.

ttty 12y ago

I've been saying this for years (: happy to hear

beat 12y ago

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.

cognivore 12y ago

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.

VieElm 12y ago
EcmaScript 6 and 7 are actually adding beautiful language features. JavaScript is changing in a big way, a lot of new JavaScript will not even resemble the stuff you're probably referring to.
- angersock 12y ago
  Bug not feature, unfortunately. Were only that effort spent on eradicating the old legacy libraries!
  - flaki 12y ago
    If you are saying this, you certainly didn't read the article (properly). You can not "eradicate old legacy libraries" on whim - this stuff is out there. It is used by software out there. Software that would break if things like that would be removed. You can't just rip out and change parts of it at whim. You have to work around problems - at least until they wane in popularity and slowly die out. Evolution, rather then revolution - as stated in the article. That is exactly what TC39 is doing when they are improving on the standard and JavaScript itself. Case in point: Array.prototype.values was a proposed feature - returning an iterator for the values in an array[1]. The feature was introduced and had to be backed out at least twice[2] because widely used web frameworks (in this case, Sencha) used the attribute "values" on arrays and webapps broke as the method was added to the Array prototype. And this wasn't the first case. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/values https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]: https://esdiscuss.org/topic/array-prototype-values-breaks-the-web https://esdiscuss.org/topic/array-prototype-values-breaks-th...

at-fates-hands 12y ago

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.

cozuya 12y ago
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.

ffn 12y ago

As much as I am anally pained by the following things in JS: 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.

marchelzo 12y ago
What do you mean by "native operators like ? and if uses == and not ==="?
- osconfused 12y ago
  I believe ffn is referring to the ternary operators [1] not using identity operator, but rather the equality operator. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons http://stackoverflow.com/questions/359494/does-it-matter-whi...
timepiece 12y ago
"1" - 1 = 0 Seriously, what answer were you expecting other than this? I'm really curious!
- rpcope1 12y ago
  48 might have been a much more reasonably sane answer, or just disallow operations that don't really make any sense, instead of implicitly casting in non-obvious ways.

vezzy-fnord 12y ago

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.

pdpi 12y ago

> 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.

panic 12y 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.
- taurath 12y ago
  There are dozens of very decent ways to handle flow control with JS - any time you see indented function chains it tells you this might be poor quality code. For better or worse you can choose a library or write your own - Async.JS, Promises, etc all deal with this. Some abstractions like Async.Auto handle branching paths (series -> parallel -> series) very elegantly.
  - meric 12y ago
    With coroutines in Lua, you could write: function handleRequest(req) data = db.fetch("user") return render("template.html", {user=data}) And if db.fetch and render (both made up functions) are written using the coroutine paradigm, your code would automatically be evented and non-blocking, no need to use libraries to handle your callbacks, and your code has the same style it does if it were blocking. In db.fetch it uses the "yield" keyword that would tell Lua it is about to do an async operation it should wait till it finish before continue running Lua code, meanwhile run something else instead, making it non-blocking and you can run many of these Lua programs at once on a single thread, all of them concurrently.

ossreality 12y ago

I'm sorry, I'm just laughing my ass off. Installed atom-editor last night. Took for god damn ever to install and the install size was hundreds and hundreds of megabytes. It's a damn joke.

linkregister 12y ago

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". linked: https://tessel.io/blog/98257815497/how-tessel-works-the-basics https://tessel.io/blog/98257815497/how-tessel-works-the-basi...

tracker1 12y ago
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.

malthaus 12y ago

Ah - the pain of path dependence

ForHackernews 12y ago

Reminds me a bit of this talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

DigitalSea 12y ago

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.

0xFFC 12y ago

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)

0xFFC 12y ago
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.

chondle 12y ago

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. [1] http://boxesandarrows.com/htmls-time-is-over-lets-move-on/ 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 12y ago
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. [1]: https://plus.google.com/u/0/+NatDuca/posts/De8Bv6F4fyB https://plus.google.com/u/0/+NatDuca/posts/De8Bv6F4fyB [2]: http://www.quirksmode.org/blog/archives/2015/02/tired_of_safari.html http://www.quirksmode.org/blog/archives/2015/02/tired_of_saf...

tambourine_man 12y ago

…since both Webkit and node.js used V8 as their JavaScript engine… Maybe you meant Blink, WebKit uses JavaScriptCore

flaki 12y ago
Chromium, rather than Webkit, but yes - thanks for pointing that out I have fixed this (Blink was created much later, in early 2013).

bricss 12y ago

Yeah, JavaScript rocks!

elchief 12y ago

And don't forget to write your Postgres stored functions in JavaScript with PLV8

smrtinsert 12y ago

Blind luck. Web developers had copied and pasted functions for years, a few of them grew up from that basic beginning and tried to make lemonade. Can't wait till the next big one, because this one isn't doing it for me.

aikah 12y ago

wether one likes javascript or not,this is a good article one must read about the state of javascript today.

tracker1 12y ago

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.

mahouse 12y ago

Stop trying to make Firefox OS happen.

arh68 12y ago

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.

vorg 12y ago
> 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).
DonHopkins 12y ago
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.