To be honest, I used to dislike JS not so long ago - it was hard to debug, I had to use strange conventions to write OO code etc. But after learning more about the ES6, react/flux, node, Flow etc. I can honestly say that I really, really like JS. I think that I had negative feelings towards JS because I was using it "the old way" and completely ignored the language improvements & community/ecosystem that grew aroud it. But I learned my lesson :).
I've never been a big fan of OO (classes, inheritance chains, and the like)... so for me JS was always a pretty nice fit. With the enhancements for ES6/7 it's rather nice to work with (I'm using babel to transpile though).
There is no a single site/book I use, I just search for a topic that I think is interesting. Fore example, lately I've been exploring Promises and asynchronous JS [0][1]. For understanding react & flux, you can watch 3-part series from SeattleJS [2]. This post is a good general roadmap: [3].
"Haters gonna hate." Anyone claiming that JS is the "worst thing to happen to the web" and/or that some other language would miraculously solve all of the problems present in JS should do the following, "Go create it." Don't whine about the barriers and how a new language would never be adopted because "JS is already everywhere." There are plenty of people already trying to solve this problem by actively doing something. I've worked with enough engineers that love to criticize every design choice made but when it comes to asking them what the better alternative is they have nothing to say. They just "know" there's a better way. Well, stop using your intuition based rationalizing that there's a problem and start using your creative and logical faculties to actually solve the "perceived" problem before presenting a criticism. Or at a minimum present a well thought out and actionable direction towards the solution.
I don't believe that someone needs to have a solution in order to observe that there is a problem.
The resources available to an individual for creating and reasoning are finite, and as long as one is able to give good reasons why they know that there is a better way, "there is a problem" may still be valuable information.
If it wasn't widely know that Javascript is a problem, then merely observing that it's a problem instead of trying to provide a solution would be useful. But it's a widely known problem and so complaining does nothing useful. Essentially, at this point in the game, complaining is useless rehashing of a beaten horse.
There's a whole world of problems to fix before you even get to the problem of Javascript.
Right now, the world only has 3.5 base browser engines. Those browser developers have no interest in adding a new standard language like Python, even though more people prefer that to Javascript.
So, if you were to develop a new browser language, you need to build a new browser from scratch, and then move a billion people to it.
> Man, python on the server and in the browser. What a world that would be.
If you're going to imagine that as a utopian alternative to JS, be sure to be thorough about it and imagine 1995 Python dominating the browser landscape for years and then the advancement path the language has taken on the server playing out among several browsers. Then come back and tell everybody how much prettier it looks than JS (for bonus points, how much prettier than ES6).
While we're at it, as a general rant... I think it's weird that Python keeps coming up in these conversations.
It's a nice language, it really is. But it's in the same paradigm set and productivity class with JavaScript, Ruby, and Perl (and to a lesser extent, even PHP). The differences between these languages aren't that big and they're largely aesthetic.
If you prefer it, that's fine. If you find its particular set of choices aggregate some nice marginal gains to some additional productivity over the other languages I've listed in this class, I might even think that's a credible argument.
But if you can't get past the sting from JS's warts and learn to be largely as effective in it as you are in Python -- or if you think the real solution moving forward is to turn the entire fleet of supertankers involved in the web for retooling to use a language that's not that different -- I think that you're not thinking about your tools particularly keenly or carefully.
Don't forget about the burden this would have put on python's language designers to take into account the large amounts of already running code in websites. JavaScript was and remains tailor-made for running in browsers, which has allowed it to maintain near-perfect backwards compatibility for its primary use case without killing the language itself. It's probably a good thing that no other language was repurposed for web page scripting, as it would likely have effectively forked that language.
> The differences between these languages aren't that big and they're largely aesthetic.
They are pretty big. At work I work on a Django-backed project that has a very fat JavaScript front-end client, and JavaScript is incredibly painful to work with compared to Python.
It's not merely aesthetics, but JavaScript in the browser is severely lacking in language features that allow it to scale to larger code-bases.
I use Django a lot too, but JavaScript (ES6 specifically) just isn't a big mental shift anymore. I prefer Python syntax, but Python, Ruby, and JavaScript are pretty comparable at this point.
Also JavaScript has a pretty good variety of languages that compile to it. If you like C#/Scala/Swift use TypeScript. If you like Java use Dart. If you like Lisp ClojureScript.
Dart should also feel familiar to people coming from C#. async/await support in Dart was designed by Erik Meijer (who worked on the feature for C#) and iirc he believes it is the Dart implementation is the cleanest implementation yet.
I don't see much similarity between Dart and Java.
I've done many many years Java, then hit Dart and was very impressed.
Since that I have had to do a fair bit of python, php and JavaScript at work. I think if I hadn't seen Dart first I would have quite liked python.
The problem with Dart is that once you've been developing in it for a while it spoils you from liking anything else. I really cringe with python, JS etc autocompleting to a million irrelevant things.
And going back to Java you have the slow dev loop that comes with a compiled language.
At the end of the day I've simply never had a development experience anywhere near as productive and enjoyable as Dart.
Definitely! Though, unit-testing becomes interesting, as `rewire`, `proxyquire` and other ways of changing the dependencies inside your modules when they are `import`-ed breaks.
I also came from a Python (Django, Flask, …) background and had the same issues. Tried CoffeeScript and it helped a little but eventually fell in love with Dart.
Give it a try. I like that it comes with a useful and well designed standard library (like Python).
Thanks. I did try Dart and our team spent a full month giving it our best for our client.
It was a dream to use compared to JS. One show-stopper though: browser support. At the time, IE11 was just released and Dart had issues with IE11. Also, the Dart supported browser window is only the latest 2 versions of a given browser.
This totally killed our Dart prospects, as our target users in our business are generally non-tech savvy and we need to support older browsers like IE8/IE9.
I just prefer it to be honest, I like java script it just isn't as clean and readable as python to my eyes. And while I know nodejs exists I find flask and django to be much better alternatives (for me and the way I code/think).
I'm fairly certain that complaining works, even if it's not constructive. When enough people complain about something over and over, it builds pressure to change. So I say keep complaining folks!
There are no end of alternatives out there today, from mobile platforms to research languages exploring a myriad of aspects of computer science.
Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript.
Or, they could take their own medicine, and try and write the browser in JS.
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run those myriad of alternatives alongside -- instead of under -- JavaScript.
The complexity of doing that would be needlessly high compared to just improving JavaScript. Having to integrate a C++ DOM with a JS DOM is hard enough. Think about how you handle cross-language cycles…
> Or, they could take their own medicine, and try and write the browser in JS.
>> Or, they could take their own medicine, and try and write the browser in JS.
>You mean like Firefox?
This is a very strange comment, especially coming from you.
Everybody knows that the bulk of Firefox is not written in JS. You personally have spent years of your life working on a new programming language precisely because JS is not suitable for writing a web browser.
I'll take your position on JS seriously when you abandon Rust and begin writing the bulk of Firefox in JS.
It would actually be a very interesting experiment to try running Servo Emscriptenified (with SharedArrayBuffer, of course). I wouldn't want to write a browser in the full JS language, but that's precisely what asm.js is for.
"You should abandon Rust and write in JS" presupposes exactly the kind of strawman I've been arguing against. You don't have to abandon your favorite language!
In browsers, the OSes of the web, nope, just a bad language designed in 10 days that resists all attempts to make it not bad.
It doesn't really matter if you like javascript, there's so many people who don't.
Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable?
The kernel doesn't have a DOM. On the Web, the number of GC'd objects that every "process" has to deal with exceeds the number of file descriptors by an order of magnitude.
Also, you do have a choice: you can compile your favorite language to JS, even low-level ones via asm.js.
> Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable?
That's not the choice: you can compile your favorite language to JavaScript. That's what source maps, asm.js, and the like are for. And JS is being improved all the time; it's not static.
Trying to add another language has been tried multiple times and has always failed, because having two languages that both interact with the DOM is much more difficult than just improving JS.
Semi-serious question: Other than backwards compatibility, do browsers need to have a DOM? It seems like many web app devs spend more time fighting against the DOM than working with it. Why not just make the browser expose a generic GUI model? Let web devs interact with Webkit or QT directly?
Generic GUI toolkits are very often worse than the DOM. I've worked with Swing, MFC, SWT, Android, and iOS, and all of them are significantly more complicated than the DOM is. They do function at a higher level of abstraction, and the two really nice things they give you are components and a sane layout system (solved by WebComponents and Flexbox, now if only all the major browser vendors would just adopt WebComponents...), but in general I've found that iOS development is about 1.5x-2x slower than web development and native Android development is about 3x slower, roughly on par with Swing or SWT. MFC was a clusterfuck, I wouldn't even go there.
The way frontend devs for other platforms deal with it is to specialize in the nuances of the platform and effectively build your app around the capabilities that Google/Apple/Microsoft/Sun provide. That's fine, and makes for a fairly uniform, polished experience if you have good devs, but it significantly restricts the set of apps you can build. The reason web developers like developing for the web is because it doesn't make you a sharecropper in Google/Apple/Microsoft's world, while building a full-featured GUI framework into the browser would.
I've found JavaFX's scenegraph approach rather neat. Effectively it borrows from HTML, but where the basic node set is designed to be UI elements rather than co-opting a set that was designed for text documents. It seems to take a surprisingly small amount of code to sketch up an interface.
React's not bad on the web side (especially with Scala.js) but fudging around layouts in components with divs and Bootstrap still feels clunky.
I still remember how super easy and fast was to make a GUI in Delphi/C++ Builder - what took a month in MFC/Swing took about an hour in Delphi. Even Qt feels like a massive step back from this...
It doesn't actually work on (GUI) OSes - there is a strong incentive to write your app in the language and framework that is native to the platform, because you're asking for a lot of pain and a substandard customer experience otherwise. You write your Windows apps in C# and .NET. You write your Android apps in Java. You write your iOS apps in Objective-C, and now Swift. You write your Gnome apps in C with Gtk+, and your KDE apps in C++ with Qt, and your Eclipse plugins in Java with SWT, and your Emacs extensions in Emacs Lisp. In all these cases (except Apple), you can write your apps in a different language, but virtually nobody does, because you end up fighting the platform.
Servers and command-line tools are an exception because your interaction with the host platform is limited to a few dozen syscalls that can be easily bound to a number of different languages. Not so with most GUI software.
> just a bad language designed in 10 days that resists all attempts to make it not bad.
This is unnecessarily inflammatory. I've been writing JavaScript since back when it was called LiveScript and while it's certainly not my vision of the perfect programming language, it's come a long way. The code I write now is considerably cleaner, easier and more reliable than the code I was writing in 2005, much less 1995.
Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't.
No, for OS you decide which compilator to choose. As is with browsers. There are several languages (e.g. TypeScript, CoffeeScript, Dart) which can be compiled to JS.
That is not what I personally like (the processes of compilation and deployment I mean), but if you develop for OS then you have to compile before you run... In most OS.
> Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't.
Uh, what? You do have a choice in the browser. I don't understand.
I think the web is getting better in this regard. Since the introduction of emscripten and asm.js there have been some improvements to the tooling and runtime to make it so you can just write your app in C or C++ without really thinking about JavaScript.
It's only a matter of time before other languages can have the same level of support.
...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)
14paninta's comment is dead again - shadowban? Anyway, I'll repost and respond:
> asm.js doesn't support threading.
asm.js supports threading, actually, through Web Workers and SharedArrayBuffer.
> it can't run native code.
This is true, but asm.js is relatively close to the metal. It's not very far from assembly language.
> it doesn't support meaningful debugging.
This is a tooling issue. While the situation is bad at the moment, it'll surely improve.
> it doesn't have a post-DOM API surface like pepper.
Why do you need a "post-DOM API surface"? If you just want to blit stuff to the screen, the DOM is actually no less efficient than Pepper: you can directly pass it pixel buffers, or call OpenGL routines.
Asm.js could be considered close to the metal if you were running on a Pentium 166. I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc.
With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment.
These problems all come back to the fundamental issue. There's no escape from javascript. Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility". Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web. Thus, we stagnate, and everyone suffers for it.
I've never used web workers, but as a developer who has written a lot of multi-threaded code in C++, I'm kind of glad that as a user I don't have to suffer poorly written non-thread-safe JavaScript. I've seen some terrible multi-threaded code by developers who just didn't get it. I suppose that's why web workers are designed the way they are: to make it easier for developers who maybe don't quite get the intricacies of multi-threading.
> I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc.
It has all of these things. It has SIMD now, 64-bit support is improving, IEEE-754 is supported (though some of the checks aren't available yet, I'll give you that). Give it time.
> With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment.
Yes, but this stuff isn't applicable to asm.js. It shares a heap between threads, it's just like your old native code, and everything is triggering race conditions^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B hunky dory.
> These problems all come back to the fundamental issue. There's no escape from javascript.
What's wrong with that? If you don't like JS, you can compile to it. It's an excellent compile target.
> Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility".
It's not just a compatibility hack, though managing to work on everything with no updates is a killer and awesome feature. It also avoids unnecessarily reinventing the wheel. It reuses as much of JS as possible. That's good.
> Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web.
...well, yes, they're fracturing it. And usually needlessly. There'd be no benefit to a new language on the web. There's nothing a new language can offer which JS doesn't have.
> Thus, we stagnate, and everyone suffers for it.
What stagnation? Everything is moving rapidly. Things are improving all the time.
Simd.js is only supported on one and a half browsers, is only supported on a single platform, and only supports two data types. I'd hardly call that supported, more like being hacked together. Its current implementation requires you to waste quite a few clock cycles and bytes of memory if you want to do things like graphics operations. 64 bit support is at the, "hey, you can store numbers. Have fun creating all the operations for them" stage." Furthermore, it deviates from the IEEE-754 standard in things like number handling -- Math.max(5,NaN) should return 5, not NaN. This means that libraries written in other languages and transpiled using emscripten and the like will not behave as they should.
I'd say that the weaknesses of web workers is absolutely relevant. Though you see it as protecting the coder from themselves, there are design patterns out there, like publish/subscribe, that are useful in letting threads communicate, but not generating race conditions. DOM access and the like can be done sanely, but Javascript doesn't even give you that option.
Given the reasons described, it's a rather poor compile target. It's a plodding beast of a language that mishandles numbers, requires circuitous coding to handle basic concurrency, and otherwise behaves in ways other languages don't. Transpiling just barely hides its flaws.
I will restate that it is a hack, and a rather ugly one. Its attempts to maintain compatibility leave us with a virtual machine that is increasingly obsolescent. An "assembly language" designed in 2013 shouldn't be lacking support for 64 bit integers (or 8-bit or 16), should have good support for vectorization, and should provide some sort of register and/or stack model so that you can better clue in the vm as to what items are going to be frequently used in functions. The missing features could be handled much like JSON was early in its life, by including a library as a fallback. It would probably end up looking ugly as hell, but at the same time, it would work, and give a lot more long-term benefits.
Regarding alternative languages, Javascript isn't always the best language to describe a problem in. Sometimes your program's better written in C, or Lisp, or Fortran even. Why should you force your problem to fit the language?
Regarding stagnation, you can move quickly, yet not really go anywhere useful. COBOL had 7 major versions and several minor in 14 years. Does it mean that it's a useful language today? The stagnation comes in terms of how people think of problems, and how they try to wedge those problems to fit into Javascript. The web would be a much better place if we allowed more experimentation into languages and behavior.
Well, Dart would've been one other language in the browser, sure. But it's a language not that different from JavaScript in actuality. The benefits seem few for the work needed to support two different languages. Compiling to JS, which fits Dart quite well (probably because it was designed to compile to JS well), seems more productive to me.
Some were excited Dart might lead to some sort of bytecode VM being added, but that didn't lead anywhere. And since then, JS has become more bytecode-like, so it doesn't really matter now anyway.
As more and more people write software in languages that compile to JavaScript instead of directly hand-writing JavaScript the demand for JavaScript becoming a better compile target grows.
In that sense adoption of Dart, ClojureScript, TypeScript, Elm et all will continue to accelerate JavaScript (language and runtime) improvements.
All part of the plan. I've been saying this since 2012, Dave Herman and Alon Zakai of Mozilla Research (asm.js creators along with Luke Wagner) said it before me:
> but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised
None of these problems would be difficult to address if the four-member vendor cartel which controls web "standards" was willing to adopt NaCl. Of course they don't want to adopt it, but that is the real problem right there. Of the four, two members (at least—maybe now three) have an active interest in holding back the Web to protect their native app platforms, while one would rather reign in Hell (through its position of shared mastery over the Web hairball) than go broke in Heaven. As to support for other languages, I only have to point out that one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation.
Nope! (On everything you wrote, including "the" and "and".)
Also: loser talk is loserly. PNaCl (did you mean PNaCl not NaCl? NaCl was never proposed by Google for the Web) like Dart fell to physics. All else is stamp collecting.
You didn't link to any of my comments, so let me help your reading comprehension.
My point then was that if Google had had MS's IE4-6-era market share and lack of scruples, they could have pushed Dart into Chrome and started using it in their web properties, and the lack of equivalent performance between DartVM and dart2js -- especially due to lack of bignums and other affordances in JS, which lack Google materially increased by choosing to invest in Dart over JS -- would have stunk. It would have verged on the monopoly abuse of which MS was in fact convicted.
My point was not that JS must be the only way to run Dart simply because I or anyone at Mozilla (or anywhere else, MS and Apple included) prefers JS. That would be dumb, and it's clearly not what I wrote.
Browser vendors have to keep JS improving. That's a given. Adding the extra costs of DartVM and the inter-heap GC and write barriers to glue it into the shared DOM client side is a huge tax, which would have helped kill Mozilla faster. MS and Apple wouldn't pay that tax. Why should anyone? Again it's not about JS being uncompetitive. "Competitive" is what browsers are when they run web content better and faster. Dart has very little to do with this.
JS is very, very hard to replace, for reasons I summed up as "physics" (apologies to Rutherford) and won't belabor here. Yet the Dash memo proposed to do just that, to replace JS, using lame assertions about how JS couldn't be fixed.
That was not just lame posturing and excuse-making for a Lars Bak retention program. Given Google's power, it was a disservice to the Web as a standards-based and ever-evolving platform, whose caretakers are obligated to keep working on it in the open, not try proprietary end-runs. (Yes, of course, many people at Google work hard to improve the Web. Good for them, but not relevant to what happened with Dash.)
I'm happy to say I was wrong to worry about Google succeeding in acting like MS did with ActiveX/VBScript. Not that some at Google didn't try (or won't again with other stuff), but they failed with Dart. I predicted that, too, as an ultimate outcome after wasting years and megabucks -- including real opportunity costs to V8 and JS. So too did many at Google predict this crater.
Dart's a compile-to-JS language now, not due to any preference for JS by anyone at any browser vendor.
> My point was not that JS must be the only way to run Dart simply because I or anyone at Mozilla (or anywhere else, MS and Apple included) prefers JS. That would be dumb, and it's clearly not what I wrote.
I've never suggested that this is what you were saying there. Here I pointed to it as evidence that I was right that "one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation", where by "competitive" I was obviously referring to performance. Since we're agreed on that, the claim that everything I wrote above was wrong 'including "the" and "and"' goes out the window. (What I did point out to you at the time is that this was hard to square with the claims being made elsewhere for JS' wonderfulness as a compile target.) Your take on Google's intentions in proposing Dart is also completely in line with my argument that the vendors of major browser engines have huge power basically not constrained by anyone besides the other three vendors, as well as motives that don't always align with the public interest.
The "and" and "the" line was from Mary McCarthy in reply to Lillian Hellman. You're Hellman :-|.
You wrote:
"As to support for other languages, I only have to point out that one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation."
The empty rhetorical flourish ("I only have to point out...") aside, this is rank question-begging. You assume that JS as Dart target being too slow must mean DartVM should win because of "competitive" force. Wrong on at least two counts (I'll ignore market power abuse):
First, DartVM may be faster at semantics JS supports due to optimization problems on the JS engine side. V8 in particular lost its founding team to DartVM, except for some moonlighting. Therefore "competitive" does not mean that JS cannot improve to be as fast when compiled from Dart as when the Dart source runs in DartVM.
Second, DartVM may have types and optimizations that JS lacks, bignums for example. Again "competitive" does not mean JS cannot change, and in fact bignums have been on the ECMAScript Harmony agenda since 2010, before "Dash" leaked.
In any competitive market with deep tech, there are lots of ways to meet a set of developer-facing language support/performance requirements. Even with all Google's billions, Dart and Chrome decision-makers couldn't ignore the compile-to-JS alternative and continue to justify developing and shipping DartVM + OilPan + all else not fully in hand to support JS and Dart with no performance regressions. Compiling to JS is the sole path forward for Dart on the Web precisely due to competition.
Citing my argument about bignums is perversely wrong, unless you assume DartVM is the only solution to any DartVM vs. dart2js performance disparity.
Such an assumption, like the one you seem to have made about NaCl, is anti-competitive, uneconomic, magical thinking. It requires indefinite amounts of time and money to fund all the work to have two VMs, a super-GC to collect cycles, write barriers as part of that super-GC, and more optimization to overcome the performance regressions imposed by those barriers (if possible). It assumes JS can't more cheaply be extended to be a fast-enough target language. You offer no proof.
BTW, you started out with NaCl and I still think you're mistaken about something pretty fundamental. NaCl was never proposed as a Web standard. Ok, suppose you mean PNaCl. The problem remains that PNaCl required a big API, Pepper, to reach the guts of chromium/Blink (originally WebKit) and the underlying OS. The problem with PNaCl was always Pepper, and again: competition killed Pepper as a cross-browser API.
It takes longer (it would have happened sooner with more cooperation from Google earlier, instead of the malinvestment on these two big follies), but JS is getting SIMD and shared memory threads, which are among the last few bricks still standing in the Pepper wall.
So PNaCl is evolving with Emscripten/asm.js now -- precisely due to competition -- and I would not hold my breath for PNaCl to remain based only on LLVM bitcode (with fixes requiring years and millions, to remove unspecified behavior). But feel free to hold your breath and then blame the "vendor cartel" if you like.
On that "vendor cartel" point, there are more web engines coming along, Servo (an open source project with multiple paying companies involved) among them. There's no cartel, just a big compatibility hill for any new engine to climb.
Adding gewgaws like NaCl and Dash slows down that climb. It's uncompetitive for the would-be market entrant. Why you think this requires collusion ("cartel") or Satanic pride ("reign in Hell") is unclear. Do you get many billion-dollar free lunches where you live?
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript.
Just let me know when Intel, AMD and VIA are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- x86 assembly language.
14paninta replied to this, but their comment's dead (shadowban?) - anyway, I'll repost it here and respond to it.
> What does that even mean? It's nonsensical.
What it means is that the situation with browsers is not much different from the situation on native platforms. CPUs support one language, the browser supports one language. And yet I don't see anyone complain about CPUs only supporting one language, because you can compile anything to it. The same is true for JS, so why do people complain?
>Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined.
Underneath JavaScript is native code produced by a JIT compiler. It's not super-intricately intertwined with the underlying OS and hardware, but it's not incredibly abstract either.
>You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture.
>You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations.
You can also retarget stuff compiling to JS to compile to something else, like Lua.
>Microsoft can ship the CLR for ARM, x86, PowerPC.
> You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you.
Yes, everything must pass through a JS JIT... you don't have access to the underlying native code. But everything on a CPU must pass through its microcode translator. That uses functionality it requires which is unavailable to you.
> Microsoft can't ship a fully functioning CLR for JS.
This simply isn't true. You can write a CLR for JS that compiles to something like asm.js at runtime. Bytecode VMs with JIT compilation have been written in JS before, see Emterpreter for instance.
> What it means is that the situation with browsers is not much different from the situation on native platforms. CPUs support one language, the browser supports one language. And yet I don't see anyone complain about CPUs only supporting one language, because you can compile anything to it. The same is true for JS, so why do people complain?
Because we don't write assembly ourselves. Unless we are doing micro optimizations, we don't even have to look at it. We do however, have to look at your shitty JS.
JS is not the "assembly of the web". It's a high level language. Your comparison is idiotic.
If you write in Coffeescript or Clojurescript, you're not writing the "assembly" yourself. It's a perfectly valid comparison, and JS being a high-level language doesn't change anything.
Well, you don't write assembly because it's not pleasant to write in. JavaScript is actually quite high-level by comparison, so you can write in it, and many people do.
> Unless we are doing micro optimizations, we don't even have to look at it. We do however, have to look at your shitty JS.
You don't need to look at generated JS either. If the tooling sucks then you do, but that is only because we live in early days, and the tooling isn't quite there yet.
> JS is not the "assembly of the web". It's a high level language. Your comparison is idiotic.
It is a high-level language! But it is also a good compiler target, and contains a low-level language (asm.js) which is also a good compiler target.
Yes, the Windows Script Host. But I don't believe two languages could very effectively talk to eachother, right? Couldn't they only really interact with the native code stuff (DOM etc.), i.e. the easy part?
"You haven't single-handedly brought about the adoption of a superior client-side language in browsers. Therefore, the double/triple-equals thing was a great idea."
The correct solution is to write a DOM interface for Python and start distributing browsers with Python VMs. Python's not a perfect language but it's much better than JavaScript. There are acceptable alternatives besides Python too, but that would be my favorite. I don't see why we need to invent a whole new scripting language for client-side execution on the web, the problems really aren't that special. I know the history of JavaScript and I'm not saying it didn't serve a purpose for a time, but that time has passed; it's time to move on and put in a big boy programming language.
I sometimes wish Javascript would take more hints from Python in getting some of the details right. For instance, it would be nice if == would work so that ["foo"] == ["foo"] and { foo: 1 } == { foo: 1}. But I suppose fixing that would be a too bold move.
I like Javascript, in many ways it's a neat little language, but manipulating the small little ad-hoc data structures (arrays and hashes, and combinations of them) that seems to be half of most programming tasks is definitely a step backwards compared to Python.
> like Javascript, in many ways it's a neat little language, but manipulating the small little ad-hoc data structures (arrays and hashes, and combinations of them) that seems to be half of most programming tasks is definitely a step backwards compared to Python.
I'm a Python fan but I can't disagree more on that point. Python has terrible lambdas, and poor idioms when working with collections (list iteration over chainable/fluid interfaces).
Underscore.js, which at this point stands for 'idiomatic JS for collections', and the ES5 methods on arrays (filter/map) which are largely supported now provide a better way to handle arrays & hashes than idiomatic Python. With ES6 fat-arrow functions it's even better.
It's one of Python's biggest weaknesses when compared to other dynamic languages IMO -- that the idiomatic way to deal with 'collections' is not a chainable/fluid pattern, but instead to do multiple list comprehensions, or use the ugly filter-plus-lambda patterns which compose badly.
Double evens in a list:
ES6:
[1, 2, 3]
.filter(x => x % 2 == 0)
.map(x => x * 2)
ES5:
[1, 2, 3]
.filter(function(x) { return x % 2 == 0 })
.map(function(x) { return x * 2 })
Python:
map(lambda x: x * 2,
filter(lambda x: x % 2 == 0, [1, 2, 3]))
# or
evens = [x for x in [1, 2, 3] if x % 2 == 0]
[x*2 for x in evens]
The ES6 & ES5 JS examples are both clearly superior syntax IMO. More readable and the anonymous functions support multi-line so extend to more use-cases.
EDIT: Removed the word 'objective' because I'm talking syntax.
> You don't need the backslash on the first, making it a little cleaner
I was not trying to illustrate that the backslash made it ugly (I've removed it - I was pasting from a repl). It's ugly because of Python's lambda syntax and the fact it does not compose 'sensibly', as compared to fluid interfaces. The logic is back-to-front for one.
> But the list comprehension version is just completely wrong:
No, it's not at all wrong. Your one-liner is not better and (I hope) would probably upset most teams for being less clear.
I was providing a like-for-like example. The multi-lining is not the criticism of the Python version. It's the composition that's at fault, the fact it does not feel like 'two coherent operations over a list' with two distinct conditionals.
The ES5/ES6 examples demonstrate this much more clearly IMO.
What you're saying, then, is that it's terribly confusing [for you] when someone uses a list comprehension fully?
Presumably, these also are not completely clear to you:
> [x * 2 | x <- [1, 2, 3, 4], even x]
[4,8]
> [x * 2 | x <- filter even [1, 2, 3, 4]]
[4,8]
What, exactly, is not clear here? This is the essence of composition; to use clearly defined things together. I can appreciate a good pipeline as much as the next guy, but to say that this is somehow more complicated and hard to read is to overstretch a little bit.
To say that a pretty uncluttered list comprehension is some challenge to read is just hyperbolic. These pipelines, even with newlines, can get pretty long and terrible too.
As humans, there is always subjectivity, even in things we declare objective. I'm willing to admit that :)
It's easy to pedantically point out I used 'opinion' in the same sentence as 'objective' but I'd hope you could apply 'the context of programming' to gather what I actually meant.
When we say 'objective' over matters of syntax I tend to think of 'If you put N programmers in a room they'd all agree this was better syntax'. That's how I feel about the above examples I posted.
That said I've edited my comment so I don't inflame other commenters to point out my glaring contradiction :)
Would just like to point out that though Haskell may be an interesting language this url and title itself is still needless, passive-aggressive douchebaggery from the author responsible, and a turnoff to many JS devs like myself who aren't fools and may want to consider Haskell one day.
'The depths to which JavaScript sucks are well-documented and well-understood.'
Same applies to Haskell. As with any language, humility please.
The simplest solution would be to specify a VM for the web - that way people could use whatever language they like. Using JS for this purpose is suboptimal.
This would require people like Eich to entertain alternatives to his diseased progeny.
Although your suggestion may be popular, it is, in fact, suboptimal.
If one believes that "JS is the worst thing to happen to the web" and that "some other language would miraculously solve all of the problems" then going off into the wilderness to "create" is almost certainly a dead-end endeavour. A language is only one component of what's needed to replace JS - there's also winning over 4 major browser vendors who've dumped no trivial quantities of money, time, and PhDs into polishing this particular turd.[0] Then there's the standardisation peeps and so on. It's not so much a technical challenge - many existing languages could add support for DOM APIs and become an in-browser candidate relatively trivially - but a political one. And when was the last time you heard of someone solving a political problem by saying "hey guys, I've got a great idea here"?
Some not-absurd propositions:
1. "The finance system is shit"
2. "Modern government is shit"
3. "JS is shit"
All 3 of these have many potential non-shit replacements - but things never change. Why? Because barriers are very, very real. These things could only ever fall to the most expertly executed, well resourced, and lucky of targeted attacks.
The only viable strategy for the average "hater" (whose "hate", incidentally, is emphatically not invalidated by his lack of perfect solution) is to try to affect top-down change. Now, no one person is likely to achieve this - even exceptional people have a fearsome challenge when faced with groupthink (Galileo, anyone?)
So what is in the "haters" toolbox? Well, seeing as web standards authorities are run like district councils in the 1980's (go try to find out how to make your view officially known on an ECMAScript draft), us in the peasantry have little but our ability to create and maintain a murmur - and occasional scream - of discontent which hopefully, one day, might have some psychological effect on those who do hold the power, because lord knows it's not us users. You may recognise this particular strategy from historical great hits such as "representative" "democracy" and friends where it has been, on the whole, a slow, inefficient, wasteful, but occasionally effective way of going about things.
So my well thought-out and actionable strategy is to ignore this advice and continue to grumble - and, if you can manage it, try to be just a little bit louder than last time: shit adds up at scale.
[0]: Mr Eich told me himself that they're too invested in JS, see https://news.ycombinator.com/item?id=9264531
There's a difference between spouting negative emotion filled complaints into the ether (or claiming things are "shit" or a "turd" on random hacker news comment boards) and positively engaging in a community to effect change. All of the statements you've made are just a more articulate re-hashing of the same facts that everyone knows. You're engaging in the same cycle of "Problem here! Barriers!" If everyone took the viewpoint you've described and extrapolated it into the rest of life nothing would ever be accomplished. Yet somehow, here we are flying around the world in a day and walking around with futuristic computer phones in our pockets. Just because you think the barriers are too large for you doesn't mean they're too large for everyone (and resources are something you accumulate, you don't wake up one morning with them at your beck and call).
"...but things never change." I think you're wrong. Things do change. They just don't change at a pace that is fast enough and obvious enough for someone who feels passionate about an issue (Gay rights, Women's rights, Black's rights, all civil rights crusades, anyone?) And it often takes a long time for people to realize they need to be actively engaged instead of complaining from the sidelines before any change occurs.
By all means, continue to grumble on comment boards, just don't act surprised or upset when the direction of the thing you were grumbling about doesn't go the way you want it to.
I'm one of the people who says JavaScript is the worst thing to happen to the web, and I don't need an alternative to say that, because my issue is with what JavaScript does, not how it does it. An alternative that does the same thing wouldn't solve my complaint.
I don't want a web where all my software and data is owned by other people who don't have my best interests in mind. JavaScript allows "free" websites to replace programs running on my machine which is fundamentally opposed to my goals. I don't want all the power that computers have brought to humanity to be concentrated in the hands of corporations, I want it to be free for anyone to use. I'm glad JavaScript is shitty and I wish it were shittier, because that would slow the growth of corporate control over our capabilities and data.
The most pervasive and harmful companies all use JavaScript and couldn't do the harm they do without it (or, I suppose, an equivalent technology).
I would venture that I could solve all the problems you would solve with open source JavaScript with another programming language, because almost no program actually needs to be a web application.
I have learnt that if I click a javascript post and see a title and author slash screen and nothing else apparently I must start using my right arrow button.
The first thing I tried was hitting the down arrow key to scroll.
The second thing I tried was clicking the blue text, which brought me to Brendan Eich's Twitter page. And then Twitter did what Twitter does, and popped up a sign up/log in dialog in front of the content so I can't actually read any of it.
I only figured this out because about a year ago I ran into a similar issue and poked around the source for 10 minutes to figure out what was going on. This time only took me 1 minute :) Of course, just like last time, after I realized it was another useless slide deck with no context I left the page.
If you haven't seen a Brendan presentation, they are quite enjoyable. Last time he was playing some zombie video game in the middle of his presentation. He insisted on not killing zombies with a shovel using instead deployable automatic turrets. I'm sure he uses the shovel when he plays alone though.
Javascript's is actually growing very well and fast. It's quite surprising how soon it will have everything.
In a way it can be compared to PHP - soon it will be a giant toolbox. The difference is that every tool was chosen and added one at a time. It ends up being a very good toolbox. I'm sure productive programmers aren't complaining. Pure FP programmers can always compile their ClojureScript to Javascript. For me, ES7 Javascript is already making me happy.
So good to see String.prototype.startsWith and String.prototype.endsWith in ES6. I've ended up implementing these in too many projects. I look forward to using these in 2020 or 5 years after that, when IE 8 finally sunsets. (I joke of course, since you can use ES6 to 5 with IE 8 caveats with the modern taskrunners).
EDIT: Blockscope... what? More than a few of these changes point to JS being a functional version of PHP, but doesn't blockscope just fundamentally change the language?
> In Java you legitimately have alternatives, since the alternatives can make the same raw OS calls that the java.util.Date library does. Not so in JS. So instead we HAVE to work with Date and work around its many warts.
Uh, what? Yes, JavaScript's Date is the only way to get at that browser/OS stuff. So an alternative will use Date underneath to obtain that information. That doesn't mean the end-user has to work with Date.
I'll add that timezone information shifts politically over time... It'll never be consistent... your best bet is to ship all dates in UTC as much as possible (which `.toJSON` does) and display in local (which `new Date(jsonstr)` does).
Dates are evil, even in C# with offsets it's not easy... and that's probably the best implementation of dates, with consistent updates I've seen.
> your best bet is to ship all dates in UTC as much as possible (which `.toJSON` does) and display in local (which `new Date(jsonstr)` does).
Goodness yes, I really wish more sites did this. If you're asking a user what their timezone is, you're usually doing it wrong. Send UTC to the client, gracefully upgrade with JS to local time.
This also solves those pesky DD/MM/YY vs MM/DD/YY issues!
And while there are libraries which wrap Date in JS, there is no replacement that I've seen anyone propose. Why is a replacement needed you ask? Because Date still has exclusive access to a lot of underlying browser/OS DateTime information which isn't accessible any other way.
In Java you legitimately have alternatives, since the alternatives can make the same raw OS calls that the java.util.Date library does. Not so in JS. So instead we HAVE to work with Date and work around its many warts.
I've used quite a few DateTime libraries extensively, I'm yet to see someone "better" the DateTime .Net class. It "just works" and has few to no "gotchas."
I don't think anyone would say JS's date situation is better than .NET's. .NET's is excellent, I agree. I wish we had something like that. You can't even reliably get the current locale in JS, it's insane.
Well, at least Java didn't win. Those not old enough to remember "applets" may not know how lucky they are. Eich deserves credit for all sorts of things, but not least for saving us from that. And who knows what scripting languages the browsers of tomorrow might support?
It's because the best language is the most ubiquitous one.
You can paper over syntactic annoyances and semantic confusion with a mental mind-shift, and once they do, they become barriers to entry for your competitors. You can't paper over an inability to deploy your software in front of a customer. From the POV of "what's a showstopper, vs. what's an annoyance", ubiquity is the most important feature a language can have.
An "ideal" language is so much more than just the type system or safety or expressibility. This is true of natural languages just as much as computer languages.
It has just as much to do with the tooling, community, support and adoption - again, just like natural languages.
I think the ubiquitous languages ARE the best languages because the purpose of any language, natural, computer or otherwise is to transmit information and meaning. And the ubiquitous ones are, by definition, best suited for that.
I spent a long time avoiding JS at pretty much any cost. Then I bit the bullet and learned how to work in it, really learned (in 2010 or so). I've liked it a lot more ever since, but a lot of that had to do with my previous ignorance to things like closures and first-class functions, which of course are not specific to JS at all.
There are certainly really bad languages (say, brainfuck). Once you admit that some languages are worse than others, you admit that there can be a hierachy. Of course, it's possible for the hierarchy to have a 256-way tie for first place.
I think the ideal would be closer to the asm.js side of things than the JS side.
It's nice that I can inspect the source of any page and read high-level code, but the tradeoffs aren't worth it anymore. I'd much rather have a generic (and FAST!) low-level language with lots of compilers from/to high-level languages.
We sort-of have that today, with languages that compile to JS, but the reality is that 90% of the time you're going to be writing JS, or at least dealing with it. And personally I'd like to avoid that as much as possible.
Just do systems development on narrow hardware platforms, and you won't have to deal with JS at all.
I don't mean to be snarky, but the reality is that JS is the common interface available to all browsers to access internals in a consistent API. In order for anything else to come of age it would take the cooperation of at least three major browser vendors along with a decade for older deprecated versions to disappear. It's not going to happen, get over it...
JS is a pretty nice language and with sourcemaps and tooling, there are a number of other languages that target it. Evolution is happening, and fighting it is like trying to pray to your devine entity to be saved from it all.
Self was bad because prototype based languages are not intuitive. This is why we get the endless years of people trying to explain why it's good or how to use it and endless "discoveries" and "frameworks" to leverage "new" tricks. JS is a mess because it's prototype based, to start. Same reason Pony is more progressive than Erlang (Prolog syntax?).
JS is a mess because it's prototype based, to start.
It's internals are prototype based. The user-visible layer is essentially class-based, but lacks syntactic support for both inheritance and composition.
Unless you have all of the optimizations available to the lowest level you are restricted which is why people complain about "only JS".
There are no optimizations missing from x86 so complaining about it is pointless.
Especially given the improvements in sandboxing having a more powerful underlying language could improve things (note that this doesn't mean it needs access to the API of the underlying OS, which is where Java got itself in trouble).
Unless there exists a way to peel back that layer it is immaterial. Asking for something that doesn't exist is different than asking to have access to a layer that does exist.
There's no such think as the best language... every language makes choices for either better performance, or ease of use. Not to mention style (more functional, more OO) and any number of other variations that are purely subjective not necessarily best.
To me, JS is one of the best languages out there. It's expressive, functional and versatile.
Every single presentation of Brendan has this "I made this in 10 days" thing, super annoying. JavaScript is a great example how your career can go pretty well if you're good at selling what you're building, even if it's not very good.
This isn't meant as a "JavaScript sucks" type of comment, but as a "being good at presenting your work is really important" type of comment. Too many really strong engineers aren't good at selling their work, so we end up with JavaScript.
1. I think he mentions it because it is an interesting part of JS's birth. There are some ambiguous things about JS that makes people ask, why is this the way it is? Well, one explanation is that, it wasn't a carefully planned language in its conception. Someone needed some language that worked on top of browsers really soon and Eich had to deliver something. So he must have cut corners and made some difficult pragmatic decisions to just make a language that just works on browser. "I made this in 10 days" goes perfectly with this story Eich wants to tell. It's catchy and understandable.
2. O please. Stop with this arrogance. Even if you didn't mean it, it totally comes off as "JS sucks" comment. JS as a language has a huge value in it being a first mover and generating network effect. Would you rather have that we use Java VM on browsers? Or would you rather have 12 different languages used in differently, implemented differently in 12 different browsers? To make matters worse, would you like browsers to change its languages based on what's considered a flavor of the week?
Every presentation is, for some people, the first one they are going to see about JS. It's a reminder of what is possible in 10 days, what the shortcomings may be and how long you may have to live with those shortcomings. It can't be repeated often enough.
I think he includes it as a joke .. clearly the first few slide states started "in 1993" and done "in 1995". The 10 days seems to be a self-deprecating joke on the popular (incorrect) meme.
The joke in those slides was how I went from my before-Netscape health (the picture of me doing a back handspring was from 1993; I joined Netscape in April 1995) to the after-those-ten-days-in-May-1995 state (looking like Ash from Evil Dead 3, with chainsaw for hand).
From 1992 to 1995 I worked for MicroUnity. No JavaScript there! It was not even a gleam in my eye, although I did write a language processor for editing MPEG-2 streams.
So I indeed created JS in a mad rush to get it into Netscape 2, along with other things Netscape tried as part of a platform play against Microsoft.
If I had not rushed, I would have missed not only Netscape 2, but also Netscape 3. Netscape 3 was supposed to be version 2.1, a minor release, until a company Netscape had acquired was given the browser and screwed up their release schedule so badly that it slipped into 1997 and became Netscape 4.
In 1998 or even 1997 it would have been too late to ship JS and have it make a de-facto standard. MS had already shipped VBScript as a me-too, and if they did not have JS to imitate, it would have been even more Microsoftian.
VBScript was the alternative to the JS rush job, in my settled view. I don't write this out of pride, joy, or defensiveness. I simply think it's the likeliest alternative outcome.
(Updated to correct Netscape 4 date per http://en.wikipedia.org/wiki/Netscape_Communicator to June 1997. It was so buggy that a series of firedrill releases were required to get it into barely usable shape by '98, which is what burned that year into my memory.)
Wanted - Fullstack VBScript developers
You have:
Delivered a fully functioning single page application Using Vanilla VBS.
Delivered high performance backends with ASP(using VBScript)
Advantage - you've used Angular.vbs and Backbone.vbs, and are familiar with react.vbs
I suspect that it might be simple to make something like JS in 10 days when you can effectively delegate the heavy lifting of making it fast etc. (see last slide) to many other people after it has become ubiquitous. :)
I wrote my own interpreters for my own languages, including stuff used in production. 10 days for designing and implementing something like JavaScript is pretty good.
Also, I think that the number of problems in JS normalized by the time it took to make the first version (and that time limit was due to a deadline that the creator did not choose) is very likely smaller than in many, many other languages, if not all the remotely popular ones.
I think that's similar to how people say JSON was discovered by Crockford. Both only use things already present in the language, but they do form something new out of them. It is sort of a middle ground between discovery and invention.
Moreover, asm.js effectively already existed, right? It's not quite the same, but it's essentially a formalisation of what emscripten and the like already produced.
Modern JS VMs have type-specializing JITs. That's how they make code run fast, basically - they detect types at runtime, and emit efficient code for that.
Are numbers real? Would you say we discovered them, or invented them? Do ideas exist even if you haven't thought of them yet? If so then they are discoveries.
Overall, JavaScript is a great language. I don't find the prototype-based approach to OOP any less intuitive than the class-based approach. I much prefer it in fact.
It just so happens that the prototype approach didn't catch on early enough. Developers are now just really set in their ways and are rather pretend that JavaScript is not a true OO language.
I feel that the addition of a 'class' concept to ES6 adds no value to the language itself, but I think it was probably a good decision anyway - Because JavaScript is more flexible and adaptable than the minds of most people - It might as well use that to its advantage.
Unlike the stubborn developers who refuse to learn about prototype inheritance, JavaScript is capable of change.
Nice presentation but some of those slides are useless without notes or audio to explain what's going on. I like looking at code snippets as much as the next guy but without context I'd much rather admire my own code.
That's pretty impressive actually, but I don't currently have access to any other computers to read it on, so it's also quite bothersome.
Does anyone have an alternative URL with the content, but without the slideshow or whatever it is? I'm presuming it's some JavaScript that is causing the crash.
Yes, I appreciate the irony and no, I'm not trolling. I really want to read this!
JavaScript at 20... apparently doesn't work. I load the page and get a big rectangle that says "JavaScript at 20" and "Brendan Eich" with a link to his Twitter, and nothing I do on the page takes me to the rest of the presentation.
This is a fascinating meta-post. First, it's a slideshow, so there need to be some posts about right arrows and general complaints about scrolling (as if Eich created this content himself to post to HN, instead of to be a speaker aid for himself). Second, it's about Javascript, so a bunch of people who really love lambda syntax and significant whitespace are going to show up and talk about how much better the web would be if we all ran python in the browser.
I think the web would be a lot better if we just ran lisp in the browser. Heck, I think lisp is pretty much the answer to all our problems. But nobody ever asked me.
As someone who was developing for the web in the (late) 90s, using web browsers and java as a cross-platform UI for educational software (mac and windows!) who tried to get java applets to communicate with each other (possible but difficult, and I ended up running a local java application that the applets RPCd to), I can say this with distinct clarity: the DOM and current (modern ES6) javascript system are pretty great. Sure, they could be better in some ways, but I don't trust Joe Programmer (just for example here) to understand re-entrant code well enough to write stuff that actually works in a multi-threaded environment, so single-thread event-driven is great.
People complain about this binding and so forth, but it provides a great borrowing / mixin mechanism to the language that is just flat out impossible in other languages. The prototype inheritance system is funky, but es6 classes mean you don't need to worry about it. If you want to, you can do some pretty rad metaprogramming with it, though.
Type coercion is kind of a pain, and frankly I'd love to be able to override operators (writing === semantics for objects over and over is kind of a PITA). But seriously, Javascript is pretty great. I pass around functions, chain together stuff with functional-based approaches (front-to-back no less), and can do all sorts of hip kinds of programming with it.
Maybe if we had some truly-different language driving the web, things'd be different, but don't complain about javascript and just put forward python. Put something like haskell or smalltalk on the block. Let's go big with the radical differences. I mean, c-ish languages are c-ish languages. I only wish CSS was as nice as Javascript. If I had my druthers, that's where we'd be focusing; that and namespaces within the DOM (hello, shadow DOM!)
Okay, longpost over. And late no less - serves me right for working all day instead of reading HN. Writing JS no less.
JavaScript is like English. It incorporates the best parts of other languages. Starting from Java, you can now see the clear influence of Python in ES6/7 with generators and string templates. I think this is JS's greatest asset.
I wouldn't say English "incorporates the best parts of other languages", but you're on the right path. Like English, JavaScript's ubiquity has lead to it being elaborated such that it is suitable for a very wide range of use cases. Like English, JavaScript's ubiquity has made the language grow considerably, but it has made the language more flexible at the same time.
"We don’t just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary."
--James D. Nicoll
Interesting the Date object was a direct port from java.util.Date. It always felt a little out of place in terms of style in early javascript and this is why.
ES6 is awesome and there are so many good things happening in it. I was always a little irked that ES4 (ActionScript 3 was built on it) that had some of these elements was nixed for ES5 like typing, extending and cleaner events.
Great overview and I picked up a few things I have missed in js advancements like string handling changes (startsWith, endsWith, trim), templating with `, multiline strings!, extend, math functions, arrow, default/rest params, octal/binary literals and tons more. Many of these are probably in everyone's js libs but nice to have them standard.
I am most excited for asm.js of all due to the WebGL and gaming/app performance impact that will make when fully integrated in all browsers this year. asm.js and WebGL gaming is already giving benefit to performance in Javscript and added typed arrays to ES6.
Also in his 90's TV pic, how could you forget Seinfeld?
But could you please fix the damn boolean logic? And while at it, get rid of most implicit conversions.
Or forget all those features and bake in a macro system, so that we can fix anything without having to wait for the next ES[N] standard to get adopted.
> But could you please fix the damn boolean logic?
Last time I checked, !, && and || worked like they do in every other language.
> And while at it, get rid of most implicit conversions.
If you get rid of them JS ceases to be JS because all JS code ever written stops working, rendering the language about as useful as something I suddenly decide to create myself in 10 days.
Use TypeScript or similar if the implicit conversions bother you. You don't need to write JS directly.
> Or forget all those features and bake in a macro system, so that we can fix anything without having to wait for the next ES[N] standard to get adopted.
This was mentioned in the slides. Did you read them?
Macros for JavaScript have been available for a long time[0], you can even use the C preprocessor[1]. Also I wrote a macro plugin for babel just yesterday [2]
They don't have to remove anything, just repeat what they did with "use strict" but make it, uhh, even stricter. Just a subset of JS which is only the good parts.
Actually "use strict" actually makes JS an almost good language as mistakes are immediately flagged rather than "working anyway." But strict mode doesn't go nearly far enough in my opinion.
I will say for backwards compatibility you're always going to have to write "===" the only thing a flag would do is break "==" on purpose.
It does those things poorly, and at great expense.
Eich did one thing, in 10 days, that was market positioned such that it became ubiquitous, and he's been banging that drum ever since -- to everyone's detriment, given how much power over technical direction he wielded at Mozilla, and how much impact Mozilla had on the web pre-Chrome.
"Always bet on JS" is short for "There have been dozens of challengers to JavaScript over the last 20 years, and they have all failed to gain traction". What part of that statement is incorrect?
That's not what he's actually saying there; that's a list of technical bullet points, not market adoption.
However, even if we talk about market adoption; how is Firefox OS holding up against iOS, Android, and Windows?
> What part of that statement is incorrect?
"Always bet on JS" from Brendan Eich really meant, for 16 years, starting in 1998 and during the time that Firefox was most influential over the future of the web: "I'm never going to bet on anything other than JS".
It's a uselessly self-fulfilling declaration when its stated by a (now former) browser vendor executive.
> That's not what he's actually saying there; that's a list of technical bullet points, not market adoption.
The point is that if JS couldn't do these things, it would be eclipsed by a competitor. It instead grew the ability to do those things, and its competitors never gained widespread adoption.
> However, even if we talk about market adoption; how is Firefox OS holding up against iOS, Android, and Windows?
In terms of languages on the Web, JavaScript has always won. It's clear at this point that the Web isn't going anywhere, even though mobile apps are important.
> The point is that if JS couldn't do these things, it would be eclipsed by a competitor. It instead grew the ability to do those things, and its competitors never gained widespread adoption.
REALLY?? JS can't do concurrency by any objective performance measure against systems providing shared state concurrency; how is a competitor going to eclipse it when the lowest-level syscall interface available to target is JavaScript?
> In terms of languages on the Web, JavaScript has always won. It's clear at this point that the Web isn't going anywhere, even though mobile apps are important.
It ought to be indicative of something that the web is faltering in market segments where programming languages do more than move DOM elements around.
Oh no, I've been caught, called out on my Throne of Skulls on my Skull Island again! Yes, I had so much power over all the people working on Mozilla, I clouded all their minds with my superpowers.
And post-Chrome, I still do, since apparently in spite of Chrome, your hero, villainous-me managed to kill Dart as a 2nd VM-based language in browsers -- even in Chrome. Mwahahahah!
While this story keeps getting posted again and again, I'd like to step in and provide some first hand experience here instead of just claims, hearsay, or obviously biased opinion.
I had the... experience of working next to Brendan Eich for a while. His Throne of Skulls is no joke and I have no idea how it got past either HR or the ergonomics coach. I kept cutting myself on the damn thing when I'd bump against it, had to keep a first aid kit at my desk. We didn't even know where the skulls came from either, but more kept appearing mysteriously each day.
The laugh was annoying too. I'd be sitting there trying to work on the monolith of doom (which was actually the name for multiple technologies, but no one could decide which was doomier so we just called them all that) and all of the sudden, it's evil laughter time. Nothing breaks concentrating on code like a roar of pure malevolent guffawing. I'm sure many engineers at startups can sympathize.
Much like the rest of this comment thread, I have no idea how this much of the web happened around this man.
I'm just responding to the accusation as if Javascript is the known culprit. In those cases, chances are the code itself is the problem and not the language. I can code a page that will likely hang the browser but that doesn't mean I don't take the responsibility of the code that I wrote.
Anecdote, but I've got 30 tabs open in Chrome and I'm using a Macbook Pro that's over 7 years old and it loads in less than 3 seconds.
Also, I can open it in Lynx. The un-alt'd images mean there's a bit of inaccessible content, but it's actually more or less coherent, which might be useful to those whose machines are struggling with the content or even (potentially) to those rendering opinions on whether the web just sucks.
Anecdote, IE11 "Edge"-mode still doesn't support 3D CSS transformations. It's also end of life in Win8. The presentation worked fine in Chrome and Firefox.
It only consumes a few MB RAM. But the favicon of his website is missing - that's why it looks like it loads several seconds.
> Cool presentation, but holy shit, taking ~2 minutes to load on FF and freezing the browser is not.
Do you have any extensions installed? It took less than 2 seconds to load for me in a blank Firefox profile, which isn't particularly long for any website with a decent number of images on my connection.
My only complaint is that the animations make me seasick - I wish there were an obvious way to turn them off.
My issue with it is that I click on the Hacker News link, step through the slides and then want to return back to the hacker news discussion to read the comments. Unfortunately, each slide is treated as a new history item and Firefox only remembers a finite amount of them so I then get stuck on the presentation with no way to get back to the site I was on before. Tempted to just inject this into each page I visit since the feature annoys me so much:
So, if you're on a search results page, and click next 20 times and then click back, do you expect to go back to the search form, or the previous results page?
Whilst I agree it'd make sense in that particular context for the back button to take me back a page in the results list, I'd rather the search results page made use of actual links which I can use via my browser to make a new HTTP request for another page of results. I dislike sites which insist on loading primary content with JavaScript, breaking the browser's loading feedback (animated icon, hidden favicon) in the process. These sites usually don't handle failed requests properly, either. If I were to post a form in Firefox to a site which happened to be temporarily down, Firefox would display a message explaining what went wrong and giving me the option to resubmit the entire form as many times as I want.
I also worry about the pushState function being misused to hide URLs in XSS attacks which involve query string parameters. It's clear you can also stop a user from going back from your page too, something I imagine could also be misused.
Welcome to the modern web, where bad technologies (JS, HTTP, CSS and others) are developed to the max and declared modern despite always remaining bad technologies
Depends. Sometimes people write slideshows for internet sharing, in which case they're crappy presentations but text-heavy enough to be effective. Netflix's classic "Culture Deck" is a decent example there.
But the ones that are good for presentations--that is to say, visual interest hooks, not the info being repeated--yeah, not great unless they include an audio track or something.
I didnt even realize it was a slideshow. No arrows or icons you can click to go to the next/previous slide and nothing on the website saying its a slideshow.
Thanks for your comment. After I read it I went back and clicked an arrow key and the cubeshow started.
It's literally unreadable on my Nexus 7. For some reason a bunch of slides render empty, the ones that do render load really slowly and often stop part way through rendering leaving partial text that is occasionally readable.
Depends on the slides really - you're right though some of them need their context to be meaningful. Doesn't have to be audio a scrollable transcript could suffice.
nope. Even worse are ones that don't indicate visually what they are and I stare at the screen for 20 seconds waiting for it to finish loading and wondering why my scroll wheel isn't working.
`isNaN` as it currently exists isn't terribly useful, because anything that can be type-coerced to NaN will return true. If you want to check if something actually is NaN in JS, the common idiom is to test x !== x, since NaN is the only value in JS that is defined as not being equal to itself (don't blame Eich, blame the IEEE floating-point standard). NaN, despite the name, is a "number" that's a result of floating-point calculations with undefined behavior. Sometimes that's a useful thing to test for.
Adding a new, proper isNaN function under a new namespace (Number) lets them do that without breaking the old functionality.
I think I can. The old isNaN() coerces to Number, and non-numeric strings become NaN in JS, e.g. +"LOL" is NaN. However, the new isNaN() just returns false if the value passed isn't of the type Number, which I guess might be useful if you're going to use isNaN() on non-Number values?
Before someone says that NaN means "not a number", technically yes it does, but it is really just a special value of the Number type.
Edit: Oh, zastavka's comment has enlightened me now. I think the reason they changed it is because now it'll check if it's NaN (return true) or anything else (return false), so it'd be like === NaN if you were able to do that. Previously it'd check if it coerces to NaN. I guess the new behaviour is more intuitive.
note that isNaN() will remain as it is today, coercing to a number (and so isNaN('LOL') will continue to return true). Number.isNaN() will have the new behavior, testing for actual IEEE 754 NaN values (and so returning false for Number.isNaN('LOL')). Such is the unfortunate price of backwards compatibility.
probably because NaN has a specific meaning when the value being considered is a number, which "LOL" isn't. If you're calling isNaN, it usually means you're checking explicitly for a number like 1/0, not a string. So really this is a matter of types.
Personally I don't see how this solves much, but then again I'm not a JavaScript guy.
Ironically enough, 1/0 is Infinity, which is a valid number, instead you need to use 0/0 to get NaN. Even worse, the rules for NaN aren't specific to JavaScript, but come from the IEEE 754 floating point standard.
WRT async/await, don't lazily prefer serial await, when parallel await is possible:
Serial example:
async function someAsync(list) {
let ret = [];
try {
for (let item of list) {
let res = await asyncFn(item)
ret.push(res)
}
} catch(e) { /* ignore */ }
return ret;
}
Parallel example:
async function someAsync(list) {
let promises = [];
try {
for (let item of list) {
let promise = asyncFn(item)
promises.push(promise)
}
return await Promise.all(promises)
} catch(e) { /* ignore */ }
return [];
}
Sort of off-topic, but I have to observe that slides 58 and 59 are the clearest, most succinct description of how classes and prototypes are related that I've seen.
For background on the user-defined operators and literals idea for ES7, see this: http://www.slideshare.net/BrendanEich/value-objects (it took me a little while to find; it hasn't been as prominent in recent discussions as the other items). I'm excited to see all the progress Javascript is making!
So, 20+ years ago, javascript was a scheme(-like langauge) -- but was disguised as java for marketing -- now we can go back to a more scheme-like javascript?
I wonder if we'd be better off with a proper scheme in the browser in the first place...
I disagree, function scope is not going away. So I still have to understand that. If I mix in lexical scope, I now have to think about 2 scopes, which makes my life worse.
I think one could argue that function scoping is no longer necessary - there's nothing you would do with function scoping that you couldn't do with lexical-block scoping, since with lexical scoping, you can still declare variables at a function block scope.
The only real benefit I can think of from function scoping is hoisting, reliance upon which strikes me as an antipattern.
Naming functions with 'var' or 'let' is possible in JavaScript because functions are first-class in JS unlike some common languages that don't have a functional paradigm (say Java). I think the function foo() {} syntax is mostly to make programmers coming from languages like Java feel comfortable but it does get confusing to have multiple syntax/semantics for declaring functions.
The fat arrow '=>' in ES6 adds yet another way. Personally I think the added complexity in ES6/7 mostly just add bloat and syntactic sugar rather than necessary fixes.
I wonder if it wouldn't have been better to just declare "javascript 2", and write a compiler from "javascript 1/legacy" to "javascript 2" in "javasript 2" -- and suggest browsers/implementers used that.
I mean, do we really need both let and var; function * , function and => (I suppose having to mark a function as re-entrant at least one can understand, though)?
In the presentation, it's not clear (granted without commentary) why one would ever, for new code, write:
// Interpolate expressions into a template string
var name = "Bob",
time = "today";
console.log(`Hello ${name}, how are you ${time}?`);
function dedent(strings, ...values) {
let result = '';
for (let i = 0; i < strings.length; i++) {
result += strings[i].replace(/\n\s+/g, '\n') +
values[i];
}
return result;
}
console.log(dedent `Hello ${name},
How are you ${time}?`);
And not:
let name = "Bob",
time = "today";
console.log(`Hello ${name}, how are you ${time}?`);
let dedent = (strings, ...values) => { // is this valid?
let result = '';
for (let i = 0; i < strings.length; i++) {
result += strings[i].replace(/\n\s+/g, '\n') +
values[i];
}
return result;
}
console.log(dedent `Hello ${name},
How are you ${time}?`);
I understand backwards comparability, but for at least Firefox, let won't work without marking the code in question as v1.7 anyway. It might as well have been Self, Ruby or R6RS.
While having as compact syntax as Smalltalk or Lisp might be going a bit far in the other direction -- I do wish they'd taken the time to simplify the language.
Edit2: When do you switch off your transpiler and serve native ES6? In 2020?
Original:
What do you do in 2017? What if you already code in ES6 and transpile it to JS5 at the moment. Do you simply switch from serving JS5 to JS6?
Older browsers (todays current browser) don't support "class", "let" and other new syntax constructs. The just fail with JS errors. Can one browse the web with IE11 and iOS 8 Safari in 2017? (e.g. "lifetime support" of the device)
Polyfills can be used for pre-JS5 browsers. But can you polyfill "let" and "class" syntax keyword? One can today still browse the web with IE6 and Phoenix 0.l (early Firefox), despite a few glitches and layout bugs. Many sites use polyfills like JQuery and still use JS3 functionality made popular by Crockford "JavaScript the Good Parts". JS5 added a few things that JQuery made popular.
The syntax changes between previous JS versions were smaller in comparison to ES4 and ES6 (ES4/E4X failed and was abandoned).
Edit1: I added "What if you already code in ES6 and transpile it to JS5 at the moment." as the second sentence to make it clearer. As several down voters misunderstood my serious question.
The web is a lot more broken if you browse in IE6 than you appear to think. Some major sites work OK only because they had a financial interest (single digits of IE6 marketshare) until the last few years to maintain IE6 compatibility. This will degrade rapidly, but go off the very-well beaten path today and you'll find the web basically unusable.
Backwards compatibility on the web has long been backwards compatibility of source. Sites written in the IE6 era and not touched since should continue to work in browsers of today (which is why things like vendor-prefixed features proved to be a poor idea and are mostly no longer created). You'll get some rendering oddities, but this is still very much true.
IE11 (Win8) and various devices that won't receive an update like many Android 4 and older iOS devices will be around for a few years!
Sure, you can use a transpiler and serve JS5 the next ten years (2025). What do you plant to do? It seems most simply haven't thought about the problems lying ahead.
Many were against the ES4/E4X changes that e.g. Firefox supported for some time, as they would have broken backwards compatibility. ES6 breaks backwards compatibility with the new syntax keywords and there is no fallback afaik. If there is a fallback, well then everything would be fine.
Wouldn't it be better if such vendors would ship an security & ES6 syntax support update to their old browser software?
No, people have been against breaking compatibility with old source, like changing how certain statements are parsed and executed that would have made old code now in error. This is why strict mode is opt-in and larger ES4-like changes are dead in the water without careful design.
On the other side of things, though, new features that break in old browsers are added all the time. Try and run Date.now or Function.bind in old browsers and they'll immediately throw an error. It's only through polyfilling (and in some cases transpiling) that sites work in even IE8 today, and it will be the same situation in the future if a site wants to still work on an old Android or iOS device.
But yes, staying up to date as a user does depend on a newish browser being available for the platform you're running, and it would be great if old devices could continue to get updates. Really old iOS is out of luck, but Firefox supports back to Android 2.3, so users stuck there can download that browser to continue browsing the web.
> When do you switch off your transpiler and serve native ES6? In 2020?
Never, probably. Why would you? When most browsers support ES6 you would want to write in ES7, or 8, or TypeScript, or CoffeeScript, or — most likely — in some new exciting language that will transpile to JS.
Is the only solution to transpile ES6 to ES5 until 2025 or whenever IE11, Safari 7 and all current Smart TVs and Cars and what not have their end-of-life and simply vanish? Let's remember the problems with Internet Explorer 6 and its long actual lifetime. At the moment IE8 (WinXP), IE11 (Win8) as well as various other browsers will never receive an update on their platforms.
> Is the only solution to transpile ES6 to ES5 until 2025 or whenever IE11, Safari 7 and all current Smart TVs and Cars and what not have their end-of-life and simply vanish?
Well, it depends who your target audience is. If users with old browsers don't matter, you don't need to transpile.
My question was: When do you switch off your transpiler and serve native ES6? In 2020?
Today we can use native JS5 and use polyfill for JS1-3 browser. In future (e.g. 2017) one will have to rely on a transpiler or stay with JS5 for many years - right?
Intuitively that makes sense until you reflect that plenty of much worse languages than JavaScript took months or years to design.
Honestly, much as it's a pastime to grumble about the flaws of whatever language we find ourselves using, I suspect if you could rerun history a hundred times, not more than ten of the reruns would give us a better outcome than JavaScript.
In JS, arrays are just objects where the indices are keys. There is a small bit of magic where any time you alter an array object, the length is changed to the largest numeric key the object has, plus 1.
Yeah, that's why it took you so long to get basic things in the language. The JS crowd is finally excited that they have these nice shiny things. Quite a few of those have been a standard part of numerous languages for so long.
"Always bet on JS" basically means this: "JS is too big, so all the fuck ups I and others made will eventually be fixed. Because nobody is going to try to bet on anything other than JS now."
Ok, I guess I have to explain it. (Kids these days!)
I close with a slide containing bullet points rebutting all the dumb things said about how JS-can't-do-X, not to say how great JS is, but to show that software is hackable, and if Java, or Flash, or Dart can do X, so can JS. Evolving JS or doing something else is a matter of choice. JS's priority of place is not, it happened and it makes JS very hard to replace. But not hard to evolve.
I use a pic from one of Wesley Snipes's lesser movies, "Passenger 57", where the bad guy gets TOLD in a macho-funny scene on a plane, over an in-plane phone yet: "Always bet on black!" It has a great build-up with camera-work and music to match the delivery. But it doesn't mean anything more or less than always bet on Wesley kicking that pale-eyed, blond-haired villain's ass, because Wesley is a bad-ass and way more fit than Bruce Payne (who played the villain).
JS is way more fit than the comers whose fans spewed all those bogus detractions. Deal with it.
I wish JavaScript "committed a teenager suicide" and we finally got a more sane language for the web. It's startling how much energy is spent to work around its bad design every day and it's not getting any better, people are just getting used to it (which is akin to voluntarily agree with having most of one's brain blown off). Even seeing Brendan showing off that he hacked the language in 10 days makes me sick to the stomach...
I struggle with a couple different tools that were developed in weeks or a couple months or on a plane ride.
Every time these guys brag about how quickly they put together the first version I just want to say to them, "yeah, we can all tell. And every day we suffer for it."
Yes. There's just no substitute for time. It's impressive to see something put together quickly, but the result is inevitably lacking in some (or more) ways.
In this talk, I couldn't decide whether his saying JS was written in ten days was a rueful admission that it's only natural for it to be a huge pile of shit, or some self-aggrandizement based on how quickly he managed to write it. I always found JS rather tasteless, so, naturally predisposed to think somewhat uncharitably of its author, I'm going to assume it's self-aggrandizement. This might be a bit rude of me, but if it's OK to rush out JS then slowly make it ever so slightly better over the next 20 years, then I think it's OK for me to form my opinions in the same manner ;)
Hume's Guillotine slices again! Please think through this keynote at a conference. I was asked to talk about the early days of JS. Why do you suppose that I am aggrandizing by describing "is" (or "was") as if "ought" can be derived in a moral sense?
JS happened, I made it in ten days because it wouldn't have happened otherwise. Had I thought it through, I might have insisted on more time -- but then: VBScript.
We don't get to call these shots. Taste and morality have little to do with their hitting targets (whether the ones we aimed at, or others). All the good stuff in JS came from giants on whose shoulders or heads I stood.
I'm not a nihilist or materialist, but I have to laugh after 20 years. JS was not planned out this far in advance!
Anyhoo, my sense of self does not depend on ten days in May 1995. My work on the Web, not just JS but especially on Mozilla, Firefox, and HTML5, doesn't need aggrandizement. My best work has yet to be seen. I'm not doing these talks to boast. Peace.
Just ignore the trolls, most of these naysayers have never implemented a new programming language in their life, but they feel entitled to talk about taste and morality.
I think Brendan is trying to apologize for those mistakes, a brave face on the embarrassment of 20/20 hindsight, mixed with some pride in the parts he got right.
He is now spending a huge amount of time trying to fix his mistakes, so perhaps he suffers more than most...
And I obviously referred to JS just passing its teenage years, which I would prefer it didn't manage to. I am one of those crazies that are implementing a desktop-like functionality app for creatives in a browser, created a car racing game in pure JS without a single 3rd party library, did computer vision in a browser via webcam etc. and every time I have to use JS/DOM/CSS it just makes me feel I need to go to Queenstown and jump off the Kawarau bridge...
Not to mention that as a Mozilla fanboy I even use bleeding edge Firefox OS on my primary business phone.
Check out this repo, if you have a "little more" free time: https://github.com/ericdouglas/ES6-Learning
To be honest, I used to dislike JS not so long ago - it was hard to debug, I had to use strange conventions to write OO code etc. But after learning more about the ES6, react/flux, node, Flow etc. I can honestly say that I really, really like JS. I think that I had negative feelings towards JS because I was using it "the old way" and completely ignored the language improvements & community/ecosystem that grew aroud it. But I learned my lesson :).