Hacker News Reader

Comment by lacker | Hacker News Reader

The open-source-JavaScript community right now is just the largest, most active open source community that has ever existed. Check out the stats that GitHub recently announced:

https://octoverse.github.com/

Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined.

Most of the top repositories on GitHub are JavaScript too: https://github.com/search?q=stars:%3E1&s=stars&type=Reposito...

Demand for JS developers is growing too, as websites become more complex, Node.js becomes more popular on the backend, and frameworks like React Native (more popular than any other iOS or Android library on github) start to pick up mobile developers.

JavaScript performance is also starting to be significantly better than the other scripting languages, e.g. https://www.quora.com/Is-JavaScript-v8-faster-than-Python . Not because of anything inherent about JavaScript, more that it's worth a lot of investment from big companies in JS performance.

Basically, it's not just the number of frameworks. Everything about JavaScript is taking off right now, and leading to a network effect where all the other aspects get boosted too. Sort of funny to have this happen twenty years after its invention.

View on HN

To a large extent this is true because the javascript community is busy with the re-invention of all of computer history, only without applying all of the lessons learned.

Activity does not equate quality.

Not only are they doing that, but they are insanely arrogant about rejecting criticism that they're doing this too.

You don't drop an incendiary statement like that without at least citing an example of where that has been the case.

You just summed up "the largest, most active open source community that has ever existed" with "they" and suggested that "they" are all thinking the same thing with one mind.

That seems like a bit of a reach.

With some of the comments around here being a demonstration of this very phenomenon. But then, “what I cannot build, I do not understand”. The kids may be rewriting the universe in JS, but hopefully they will learn something from it, too. When we did it, in the bad old days, it was Basic and Assembler. Those environments were about as shitty and unstable as JS is today, but otoh that may foster an appreciation for proper tools once you get your hands on them. It worked like that for me. And, besides, arrogance is the privilege of youth. It would be very strange indeed if we didn't encounter it in this space.

Dude, comeon. The browser has evolved a lot as a platform, as has the hardware power of computers running them. Maybe we're re-writing computer history, but if that's the case then it's because we have to migrate everything to javascript and the wiser old timers want nothing to do with it.

* Do you really want to write CSS without a pre-processor?

* Do you really want to control a webpage's state without JS models in the browser?

* Do you really want to update html with individual jquery calls?

* Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.

I'm glad that we have an open market to exchange people's ideas. Yes, a lot of it is crap, and even among the highly adopted packages there will be problems. But that's the beauty of the market-- people can vote with their feet.

This article sums up how I feel: http://mrmrs.io/writing/2015/07/27/too-many-tools/

> "Four–fifths of everybody's work must be bad. But the remnant is worth the trouble for its own sake." - Rudyard Kipling in 1890

> Do you really want to write CSS without a pre-processor?

Not him, but yes, I absolutely do. Pre-processors mainly have the effect of forcing you to have a build tool workflow, and the nice thing about web design is that you don't need stuff like that.

They were rhetorical questions anyway :) But you're right, I get away without preprocessors when I'm doing very small projects. And a year ago my team had a 20-second SASS compilation step, that was painful. I guess I couldn't do without it because of things like: variables, nested rules, vendor prefixes, and mixins. I use a lot of mixins in scss and I feel like my code becomes more modular because of it.

> I use a lot of mixins in scss and I feel like my code becomes more modular because of it.

Well, it does, if you don't emulate the same effect with other means. But imho, needing modularity in CSS means (for most projects that are not gigantesque) that the CSS is too big anyway. It depends on what one does, specific web apps might need it. But normal web pages never.

I have found a nice compromise, in Angular apps at least, is to make a directive (tag library) that generates my "<style>" block.

It's reasonably "thin", but I can use variables to hold repeated style elements that get mixed in various selectors.

> we have to migrate everything to javascript

Why?

What I really want is the whole browser to go away.

Okay. I guess you're welcome to do that? We browser coders will just continue to go to market faster. It's pretty cool that, if you put your work in, you can make a GUI on the browser that is accessible to all desktops and phones. That's 2 billion users.

The obvious question is: what would you replace it with? Do you want to replace it all with native apps? Or do you think that this whole internet thing is overrated?

He probably agrees with this http://web.archive.org/web/20120509105723/http://teddziuba.c...

What's wrong with native apps? They use less memory, battery, and processor than an interpreted stack. They can be more responsive than the hardwired 16ms latency built into the browser. If you need network it's not hard to open a socket. The browser itself is a native app opening sockets.

In pretty much every respect, native apps are better for the user than web apps. The person that benefits the most from web apps is the developer.

I'm not taking a side here, but I would like to advocate for a fair comparison, since you have skipped all of the trade-offs in the other direction.

For example, web apps are often easier to discover, easier to update, easier to manage (since you only have one version in the wild you have to handle), easier to launch (especially for first-time users), easier to use from different platforms, more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true), ...

There's pros and cons to both sides. Just framing the situation as "my side has these benefits, therefore there is no reason to consider your side" is not an honest discussion.

Thanks for this. I was meaning to respond to my own comment but you made the points for me. It definitely goes both ways.

> easier to discover,

How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.

> easier to update,

because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?

> easier to manage (since you only have one version in the wild you have to handle), Except when there are cache issues. Or when you have multiple servers and need to upgrade them without downtime. Not to mention all the stuff required to host your app needs to handle enough scale to load not just any potential server side data but also the entire ui, possibly every time someone loads it (opposite of the cache problem above). Must be easier though, I've never heard of any web apps being unavailable because the servers were overloaded.

> easier to launch (especially for first-time users), How is typing a or clicking a link easier than tapping/clicking an icon?

> easier to use from different platforms,

If your browser on your platform is supported. And you have the right version.

> more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true)

This is a joke, right? Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps? Pretty much no web apps use local storage exclusively. So your attack surface is not "the browser", it's the browser, the network stack, the network itself (see: ddos on Dyn, Comodo/WoSign bullshittery to name a couple from the last month alone), your server host(s), your server os/stack, your server side app logic, your server side db/storage stack.. Do I need to go on?

> How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.

Because when I come across a web app in a search engine, I can click it, use it instantly, evaluate it, and decide to stay or leave, all within seconds. No checking if the app I found supports my platform, no click-through to my native app store, no download and installation process, no delay, instant feedback.

> because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?

Not sure I follow. Are you asserting that native apps are easier to update than web apps?

> If your browser on your platform is supported. And you have the right version.

The combinations are smaller than the combinations of operating systems and phones one would have to worry about.

> This is a joke, right?

Is this a good way to have a productive conversation?

> Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps?

Do you think only web apps communicate with servers?

> Not sure I follow. Are you asserting that native apps are easier to update than web apps?

I'm saying the processes are more robust. You either have the old app or the new one. You're never left with half of each, and you aren't beholden to random caches about whether or not you get the update.

> The combinations are smaller than the combinations of operating systems and phones one would have to worry about.

That can't possibly be true. Most platforms have more than one browser available, and with the exception of Microsoft, browsers don't have a "use x.y.z version rendering" like platform sdks.

Edit: unless you're taking the approach of: it works with this specific platform device running browser X, so it must work with all others running X. In which case, why not take the same approach to native apps?

> Do you think only web apps communicate with servers?

Where did I say that? Nowhere.

Web apps must contact servers and any remotely useful app will have all its storage server side.

In addition, web apps rely on servers to deliver the very thing the user sees and interacts with. UI spoofing has become such an issue browser vendors are reverting back to make it harder for web pages to present native looking dialogs etc.

Native apps can operate in a client server model, but a great deal of them don't need to because their use case is for local work, and even those that do, are merely transferring data over that channel. They aren't dependent on the same channel for the very interface the user sees.

Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.

> I'm saying the processes are more robust.

I disagree. I think updating a web app is vastly more robust. You update the source, and the only possible issue you have is caching and platform compatibility (the former is a real issue, the latter is mostly alleviated by decent testing).

Updating native apps (due to the next point) is much more problematic because the number of platforms is much higher.

> Most platforms have more than one browser available

Yeah but you can't multiply the number of browsers times the number of operating systems, because Firefox on Linux and Firefox on Windows and Firefox on Android and Firefox on MacOS are (for 99% of the apps) the same target.

> Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.

Are you interested in a real discussion? Or just posturing?

I agree, they are better and faster! But they're expensive, from an engineering-time point of view. I think that small teams with a new product would struggle to have solid native apps on ios, android, windows, osx and linux simultaneously.

I've also gotten a pretty bad taste in my mouth about some companies pushing a native app down my throat. TripAdvisor would only show me the first three reviews on a place if I was browsing via mobile, as a way to push me to download the app. And now that they're on my android they sent me a couple of spammy notifications before I disabled them. I wanted to treat TripAdvisor like a website, not like an app that has access to all phone.

I have gotten to hate most Android apps, constantly sending notifications - spam on the screen, phone on the desk going "ding, ding, ding" all afternoon :-(

On iOS, I've been adopting a policy of refusing the request for permission to send me notifications, unless I can think of a good reason I'd want to see them. I can always change my mind later and approve it if I need to, after all.

>What's wrong with native apps?

Because you really don't need a native application to look up the time the local Thai place is open or if the local independent movie theater has a showing tonight. Installing two native apps to do that is burdensome on consumers and producers

You don't need web applications to do that either. Simple HTML will do.

> Simple HTML will do.

It will, as a side effect, save 1G in RAM.

"What's wrong with native apps?" Can you even imagine having a native app for everything we do today in browsers? An app for each Credit Card I hold. A native app for each news site I read. A native app for every social media site. A native app for all the map searches, directions, etc. we all use. Security updates? Nightmare. Multi-OS support? forget about it. We'd all be back to a Windows monopoly. No thanks.

You just described about half of the smart phone home screens.

> An app for each Credit Card I hold

If a bank/credit union/etc doesn't have a native app in 2016, I doubt they have a web app that's usable on a phone either.

> A native app for each news site I read

Right, because RSS readers and aggregators aren't totally a thing.

> A native app for every social media site

Those literally exist today.

> A native app for all the map searches, directions, etc. we all use

You realise you don't need a new app for each search you want to do? I don't even understand this premise.

> Security updates? Nightmare

Right, because having half-baked web-apps with millions of user's personal data all stuck in a big fat juicy database in one spot, just waiting to be breached and spread like herpes in a brothel has worked out so fucking well.

Every major mobile platform and the two leading commercial desktop platforms have app store infrastructure which provide automatic updates of client-installed apps.

> Multi-OS support? forget about it.

Right, because no app ever has been developed cross platform, and every web app ever created works perfectly in every browser with zero effort from the developer.

> We'd all be back to a Windows monopoly.

Wat.

Edit: additionally, a number of the things you describe, i.e. news sites, aren't web-apps in the way most people think. They offer very limited if any interaction or functionality for the user except navigating to find/read other news content, and possibly leave feedback. Those sorts of things are what the web excels at, because they're essentially used for one-way content viewing.

> The person that benefits the most from web apps is the developer.

Users also benefit. For instance, linux users can use the same web apps as windows users.

Where is the 16ms hardwired latency in the browser coming from?

You do remember that Windows is the dominant os for end users? Almost all ui's would have to be created for Windows, and possibly for the other operating systems also. That's probably a lot of extra work.

Isn't Android more or less Windows' equal now, in terms of users?

If developers were better about releasing quality, multi-platform software using their 1970s languages of choice, maybe we wouldn't have all moved to the browser.

>Dude, comeon. The browser has evolved a lot as a platform, as has the hardware power of computers running them.

Yes. It has evolved to counter-balance those advances in hardware power, in order to provide a sub-par 2000 native desktop application experience in a 2016 browser sandbox.

>Maybe we're re-writing computer history

Maybe?

>but if that's the case then it's because we have to migrate everything to javascript and the wiser old timers want nothing to do with it.

Err, why do we "have to"?

And what's with the "old timers" / hot young JS developers dichotomy?

We have to rewrite everything in JS because JS is the language that runs on browsers. :) If you were asking a higher-level why (why do we have to use the browser), look rer's sibling comment.

I wrote the phrase "wise old timers" with respect-- y'all truly have things to teach us. But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping. I suspect that "old timers" is correct maybe 80% of the time, since the complainers are probably people who have years of non-JS experience and are disappointed that the new bootcampers haven't gone through their coming-of-age programming rituals. But I have a friend who is a member of the C++ master-race, so trust me, I know that gripes about browsers & JS can come from many kinds of people.

>We have to rewrite everything in JS because JS is the language that runs on browsers.

Not much of an argument. We already have 24/7 internet connected laptops, tablets and smartphones, which is were those browsers run in the first place anyway.

Perhaps we could, and I'm going on a limp here, just cut the middleman and run on the metal?

If the problem is discoverability/installation/security etc we could focus on app stores and sandboxes (which modern OSes also have both), instead of rewriting everything on the web.

>* But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping.*

Well, you first stop someone from drowning and then you show them how to swim...

If the problem is discoverability/installation/security etc we could focus on app stores and sandboxes

To this day, I maintain that if Microsoft hadn't neglected that essential aspect of the Windows ecosystem for decades, they would probably still dominate the personal computing industry.

Uh...

Oh, you mean 'personal computing' in it's original sense, which encompasses mobile platforms as well, not just desktop computers.

Right. IMHO, a lot of the reason that alternative devices, from smartphones to games consoles, took off was they solved the biggest long-standing headache for Windows users: they just wanted to get and use software to do things, not to worry about installing and configuring and updating that software or potential difficulties with removing it or how it interacted with other software.

> we could focus on app stores and sandboxes (which modern OSes also have both), instead of rewriting everything on the web.

Show me another way to write end-user applications that are cross platform, and then (if it existed prior to 1995, or even 2005) explain to me why your particular alternative didn't take over the world.

Heck, even standalone desktop and mobile apps are now being built with web technologies (react-native, Electron, etc.) rather than GUI frameworks like wxWidgets.

I don't want to do any of these things. They are the result of bad decisions in years past.

Now more and more JS abstractions are heaped upon the pile and we call it the best thing since sliced bread. No.

> Do you really want to write CSS without a pre-processor?

Yes. The only things that are worth having one for are variables and that’s not enough to add the development overhead.

> Do you really want to control a webpage's state without JS models in the browser?

I prefer to avoid controlling a webpage’s state in the browser as much as possible.

> Do you really want to update html with individual jquery calls?

No, I want to update the DOM…

> Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.

… without jQuery, yes, because it’s designed horribly.

These practices also happen to result in a website that is actually possible to develop and view on my computer with reasonable performance, because I’m one of those users nobody cares about who can’t afford the latest MacBook.

I'll admit, you got a laugh and a smirk out of me, but this still seems like an unfair statement.

The JS community at large isn't reinventing the wheel, just iterating on a wheel as it moves, if that makes sense.

It's wheels within wheels. Eat a mushroom.

Give me a break. The entire internet and software landscape is changing and everyone is in a constant rush to stay current. You make it seem like it's some kind of concerted effort to insult the sensibilities of good, proper software engineers who know the right way to do things.

Everyone is just trying to do the best they can with the incredibly complex stack of technologies in play today.

"The entire internet and software landscape is changing"

Really? Is it Web 4.0 now?

People are changing the stack because they don't know any better and trying to justify their salary. That's the bottom line. The rush to stay current is just bandwagon-hype.

I love you.

It's easy to sit back and critisize JavaScript and the web with dismissive comments like this. I have heard variations on these same memes for many years.

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.

It's always fair to criticize so that we ask ourselves the hard questions. So, it's also worth asking ourselves if we are staring too close to the wall when we try to paint other languages as backwards and therefore bad (or at least a bad choice). Just maybe, the language feature bullet list in your head (and corresponding subtleties of implementation) isn't the thing that matters most. Maybe the thing that really matters is something not as easy to codify as a language tool chain, like human consensus.

Also, it is false association to suggest that quantity != quality is somehow particular to JavaScript. Infinite monkeys will produce infinite crap no matter what brand typewriter you give them.

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.

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!

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.

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

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.

Things re-invented in JS (and by most language communities as they evolve):

  - Build systems
  - Dependency management
  - Some form of code modularity and references between modules
  - Preprocessing/macros/templating
    - Source to source
    - DSL embedding
  - Compartmentalization of state (globals bad)
    - More advanced type systems
    - OO-ish systems
  - Forms of data flow
    - Message passing
    - Functional style (including limiting mutability)
  - Forms of control flow
    - Frameworks providing more magic
    - Calls for less magic and more explicit control flow
    - Exception handling good
    - Explicit errors better
    - Event loops
  ...

On the one hand, I really miss simply being able to use "Make" for builds (Damn you to HELL, Microsoft!).

On the other hand, I loathe the spam code that checked exceptions causes (alas MS/Anders/C# gets this right, and Java got it wrong)

I remember you writing something similar 4 years ago: https://news.ycombinator.com/item?id=5415585

It's definitely frustrating to see. And it's also frustrating to see the vitriolic reactions to anyone who criticizes the current culture of the JavaScript community.

I use React and all of its associated tools and ecosystem, and while I find them productive and useful, the whole situation is a bigger mess than it needs to be. I don't think it's necessarily anyone's fault; I don't see a willful desire to ignore the hard-won computing knowledge we'e accumulated. It just seems as though the JS community's enthusiasm has, at least recently, has exceeded the rate at which good tooling can be developed.

I think that's changing, though. From what I've seen, in the past year there has been more of a push toward building mature, reliable, maintainable JS applications. I've also seen more interest in optimization. The Closure Compiler has been around for a long time, and at least in the Angular 2 community I've noticed jump in the number of people looking to use Closure and other tools like Rollup to optimize everything and deliver the smallest possible code bundle to the browser. And ES2015's statically analyzable modules go a long way toward making more optimization possible.

So I agree, things are a bit crazy. And I agree that activity does not equal quality. But there's a lot of activity, and some of it is of high quality. I can't guarantee that the high quality work that brings more of those lessons learned to the JS world will become popular, but I'm at least seeing a positive trend in that direction.

You have to be careful with the GitHub stats. I have a few Python/Ruby projects that GitHub categorizes as JavaScript because I have a few 3rd party JavaScript dependencies that ended up being larger than my actual project.

These libraries were checked into Git because it was more convenient at the time and I hadn't set up a good build system, as they were non-critical side projects.

I know I'm not the only one who has done this in the past. I'd be curious to see GitHub stats that tried to account for this.

It is not because something is larger that it is better.

These stats prove the hype, not that it is good quality code, with good quality documentation, with a friendly and safe community, and a reliable archiving system for it's dependencies.

I have nothing against JS in particular, but there is a bit too much hype about it.

Reply on news.ycombinator.com