Hacker News Reader

> But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users.

Because JavaScript was, and basically still is, the only option for client-side web development - that is to say, it was, and basically is, the only option for distributing sandboxed, instantly-updating executable code to users at any scale. Any other language requires me to convince users to download an application that runs with full privileges on their account. (For a while we also had Flash and Java, but then we realized that Flash and Java basically also imply full privileges, in practice, because their sandboxes don't work well.)

Therefore, JS got popular; therefore, people used it. This has very little to do with the quality of the language or its libraries. Note that I am not criticizing the quality any more than I'm praising it, just saying that it's irrelevant as long as it's good enough.

Basically the same thing happened with UNIX and C at a much smaller scale several decades ago, except it wasn't about client-side app development, it was about getting things to run on servers at all. UNIX isn't a fantastic OS. C isn't a fantastic language. But, in the words of Richard Gabriel's "The Rise of Worse is Better", "UNIX and C are the ultimate computer viruses."

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

JavaScript and the dynamic web the new ultimate computer viruses. But they grew much, much more quickly, and haven't had the benefit of the last forty-ish years to get decently good. UNIX and C in the middle of the UNIX wars were at least as much of a disaster.

There's a certain amount of irony in mentioning "Worse is Better" in this context.

People trying to use Javascript as a surrogate C++^H^H^H Java will be sorely disappointed.

People trying to use Javascript as something that blends Scheme and Smalltalk will be using it as its creator intended. While this won't make the extreme purists happy, for many of us, Javascript is an acceptable Lisp.

I have come to prefer Javascript to Java (or C#), but most of my coworkers still think in Java, so that's another issue :-)

Yeah, it's very true that JS is much more of a Lisp than a curly-brace language, despite its syntax. But I think the reference is still fitting because JS is an absolutely terrible Lisp. :)

And the story of JS interpreters, JITs, etc. in browsers (and not in browsers) matches the story of C compilers in the essay, just with changes in timing:

C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language. [...]

Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.

The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.

Worse & Worserer: Windows and C++, which even more people run :-(

(with apologies to the Dumb and Dumber movies)

If Javascript were an acceptable Lisp, you could have written async/await as a small set of macros instead of waiting for a huge third party project that knows how to parse the grammar.

The reason JavaScript is the de facto standard language for front-end web development seems obvious: it's effectively the only language for that development. There have previously been other popular choices, but browser developers have killed support for those alternatives for their own reasons.

In my experience working with Perl and Python most external libraries work and are well documented. Whenever I have tried JavaScript its a vastly poorer experience. Admittedly I have far more experience with the first two languages, but that would likely find more problems with Perl or Python, no?

(I don't really do PHP, but I have a feeling that I would find the experience closer to JavaScript from talking to colleagues and reading about it).

I've never had problems with docs in JS, both node and browser. The MDN is a limitless ressource of information for the base language, and for libraries, well you're going to get undocumented libraries in any language. It might be more "obvious" in JS because of the sheer amount of libraries, but I've found python libs that were very poorly documented too.

This is a problem we should be HAPPY to have. Having libraries doing EXACTLY what we want, that's just missing docs, is better than the alternative I've found in many other languages : no libraries, so we have to do everything ourselves.

I think the other poster meant 3rd party libraries, rather than the runtime.

That said, the docs on (most of) the libraries I have used are generally pretty good.

* Prototype - excellent docs (but library since overshadowed by jQuery)

* jQuery - initially the docs were hard to follow, but they seem to have gotten better

* Angular - good enough docs, and plenty of books on the larger concepts of how things fit together

* moment.js - excellent docs

* validatejs - excellent docs

* Ramdajs - generally excellent docs, but I am less familiar with some of the FP concepts used in a few cases.

The quality on some of the jQuery and Angular plugins varies a bit, admittedly.

> explanation for why their platform / language / framework [...] did not become the de facto tool

You're implying this happened to JS because of some merit. But it didn't, it was just sheer coincidence and bad luck (for most of us at least, including users).

Explain what the coincidence was ? There are alternatives everywhere (ActiveX, flash, java, visual basic IIRC). And yet here we are, with JS.

I believe JS came here because it actually is the best language we have had in the web. It's so easy to throw shit arround, but let's be honest with ourselves, this isn't purely out of luck.

JS won out the web because it came with HTML5, not the other way around.

JS won out the web long before anyone ever heard of HTML5.

JS is the only language integrated into the browser and the DOM. Netscape rejected other languages (Python, Perl, TCL) because of syntax, so Brendan Eich disguised Scheme into Java syntax and hacked up a prototype in 10 days.

Today, Javascript is sooo interwoven with the DOM in browsers that it is near impossible to separate them. Google planned to do this for Dart, but gave up. If they had done this and other browser vendors had followed, adding a third and forth and more languages would have been (relatively) easy, because the abstraction were in place. Then we would have seen a healthy competition.

There is asm.js. Maybe we will get a "web bytecode" at some point, but that will easily take a decade and more. The pressure is increasing, because our CPUs don't get exponentially more powerful anymore. And delivering apps via the web is still going strong.

There were noon-JS languages on the web, though; in particular, VBScript was a thing in the (at the time) most popular browser. I understand that at one point there was a third-party Perl implementation too.

Unfortunately there wasn't a good way for the other browsers to implement it. Or perhaps fortunately, depending on your point of view…

1. WebKit rejected adding barriers to support multiple garbage collectors and a super-GC to collect cycles, required by Dart or any 2nd VM. See https://lists.webkit.org/pipermail/webkit-dev/2011-December/... where Fil Pizlo of Apple cites 5% throughput regression.

Dart was never going to make it, and adding 3 or 4 VMs with their own GCs is even less plausible.

2. See https://github.com/WebAssembly for progress on what asm.js showed was possible: a 2nd, initially co-expressive with asm.js, eventually more expressive, binary syntax for the Web. It's happening now, this year and probably shipping experimentally in 1Q2017.

Writing "easily take a decade" out of ignorance just says to me you didn't even bother to use google!

And now: https://news.ycombinator.com/item?id=12838335

JavaScript beats those out because a.) it integrates with the DOM b.) its the only one that works on every platform today (people seem to forget that before the iPhone, web apps were heavily Flash-based). These features are powerful, but don't necessarily reflect the quality of the language design or development ecosystem.

JS won because it was the only thing that every browser supported from the very beginning, and the various differences in implementation (of which there were many) were eventually shimmable by jQuery and other AJAX frameworks. Everything else was either some alternative only supported by one of the vendors (VBScript, Dart), or a full-blown plugin that had a different model of interaction with the webpage (Java, Shockwave, Flash, Silverlight).

It's pretty much the textbook instance of a compromise between vendors of competing interests to further the common web. Despite this, it took a really, really long time -- almost ten years -- for JS to receive additional browser-implemented APIs that brought that platform's capability to what we know today and comparable to that of what we had with plugins -- and still, not every vendor supports every spec yet, making this "open web" no less subject to vendor pressures, despite being 'open' and 'neutral' [1].

[1] https://news.ycombinator.com/item?id=12259827#12259940

> I believe JS came here because it actually is the best language we have had in the web.

It is the only language we have had in the web (modulo some minor experiments). The only reason it's popular in the browser is because it's the only choice at all. The only reason it is used on the server is because some folks are familiar with it from using (overusing IMHO, but that's a different rant) it in the browser and are not familiar with the advantages of using any other language.

I've written this before, but sometimes in my most morose moment I like to imagine what the world might have been like had Brendan Eich been permitted to implement a Scheme instead. And I don't even like Scheme!

No, I agree with you, actually. Luck plays a huge part. It should inform all of us with opinions in this area about how little our opinions really matter.

Also, I disagree that users are suffering as a result, but that is a different discussion altogether.

> But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users.

I believe that part of the reason is the ease of access to JS development. It allowed an inordinate amount of poorly trained devs to enter into the job market. Because you can quickly whip up fancy UIs and show them to unsuspecting non-techie types, you can quickly earn a reputation as a "computer whiz".

I think there were many de facto ways of doing things before this, none of which were perfect, but some of which followed better design principles.

If you look at software industries where security and stability is of utmost importance, you will not find these newer frameworks in use - nor the languages they use. I'm thinking life critical systems here.

There are a few condescending attitudes at play in your comment.

Consider this: just because a language is easy to pick up doesn't mean it attracts "poorly trained devs". It just means it attracts more devs, because it is easier to get into it. Putting aside any value judgement of mass appeal, my experience suggests that the most important differences between a poorly-/un- trained dev and any other kind are time and practice. So, being easy to use is a much more powerful feature for a language / framework / platform than most.

Also, we should all be aspiring to use tools that enable us to quickly spin up a prototype UI that looks convincingly useful. I'm not sure why that's a knock against JS.

Also consider this: the languages / frameworks / platforms before the web, and before JS, were harder to use and relatively very discouraging to new users (this also sometimes goes for the communities associated with those languages / frameworks / platforms).

We all started from a place of ignorance as software developers, and many of us never would have left that place if it weren't for someone looking at us and seeing a computer whiz in the making.

> So, being easy to use is a much more powerful feature for a language / framework / platform than most.

I never said that JS was easy to use. I said it was easy to access. With JS, you don't really need an IDE, compiler, runtime etc. You need a browser, and a text editor and you can get started. It's unlike a lot of other languages in that way.

In some ways, I'd argue that languages like JavaScript are harder to use, or at least harder to use well. There is a reason that languages like Ada exist with very strong type systems. Granted, Ada is not a web development language, but I think my point still holds true since languages like TypeScript are making inroads in this arena.

I think spinning up "convincingly useful" UIs is part of the problem. First, in a lot of ways it's the wrong place to start for software design. It raises expectations and can create a contract in the minds of the client, customer, or user that this is what the software will do, and it will do it perfectly.

I'm not claiming that I (or any other programmer) started out knowing everything. But taking the time to learn, apprentice, and hone the craft of software development (the full cycle, not just writing code) is part of the game.

I think the attraction of a lot of the current web frameworks is the "whiz-bang" results you get, and it's my humble opinion that you should no more build software that way than you should a smartphone, bridge, or building. I think people need to have more respect for the software engineering field, follow best practices, and not throw out everything we've learned as each new Next Big Thing (TM) comes out.

> think people need to have more respect for the software engineering field, follow best practices, and not throw out everything we've learned as each new Next Big Thing (TM) comes out.

I agree with this sentiment, with a few (rather large) caveats:

∙ Best practices yesterday may be legacy practices tomorrow.

∙ The Next Big Thing™ is usually hidden lower in the stack (in the above example it was cheaper commodity hardware and free-as-in-beer operating systems), and while it may not force throwing away everything, it can still prompt throwing away a heck of a lot.

So, yeah, there is a lot of churn in the JS ecosystem right now. It's inevitable that there will be some sort of shakeout and some projects will emerge as de-facto standards around things like declaring dependencies, build tools, etc. The same thing happens in every successful software ecosystem exploiting a new niche.

quantity !== quality

There is a (perhaps apocryphal) story about the art class which was separated into 2 groups - one group worked on a single project all semester and the other group worked on a new project every day. People in the group that worked on a project every day produced better work than people in the "single project" group. My google-fu is weak, so I cannot find the reference.

I'm not suggesting that the Javascript ecosystem is filled with awesome stuff, but sometimes quantity leads to quality.

This is the running premise behind the book Art and Fear, which basically concludes that iteration with quality feedback is the best way to develop your abilities and produce your best work. That is, quantity is the best path to quality.

https://www.amazon.com/Art-Fear-Observations-Rewards-Artmaki...

Thank you!

Hmm. The "fear" aspect sounds a lot like what Steve Yegge called software conservatism.

Maybe because art art school you always do the same thing: so doing it continually for one semester or restarting projects on shorter times, the final thing would be quite the same, except that if you work on more small projects, you will maybe learn faster.

And, your art is yours. No artist is able to do huge harm to a whole industry by releasing some crappy painting with terrible design choices. They're only harming themselves and/or their reputation.

There is a parallel though: bad art is weeded out over time, the good stuff remains. In software it is quite similar, the good stuff has staying power, the bad stuff will be forgotten soon enough. The average half-life of a typical javascript framework is quite telling in this respect.

TypeError exception: Expected even more equals signs.

Shut up, we all know that's a silent error!