[jbeckham]

Honestly, I didn't read the entire article. By the sixth paragraph, I already identified that the author was blaming the use of a tool for bad product management and software development practices.

All of the problems blamed on "javascript" in this article aren't a problem with javascript itself, but the improper usage of certain frameworks in certain circumstances. Using a big bulky framework for an internal application where you know the user is constrained to machines that can perform well with that stack is fine. Using that same framework on a public web application that will also be hit by mobile applications is not. The problem isn't the framework, it is that the product team did not properly vet the performance impacts of the development team's choice of framework or did not properly specify the performance requirements for the product. One other option would be that the governance structure for ensuring that those requirements are met before release was insufficient. Either way, the problem isn't "javascript", but the SDLC processes used to build the software.

[TeMPOraL]

Now if majority of new websites exhibit that problem, how do you classify it? Can you really blame the whole world for misusing a tool, without taking a critical look at the tool itself?

[rauhl]

> Can you really blame the whole world for misusing a tool, without taking a critical look at the tool itself?

I’m reminded of all the folks who — in 2018! — try to claim that C is a perfectly good tool for writing large, secure systems. Never mind that it loads a gun, puts it in your hand, cocks the hammer, points it at your foot, puts your finger on the trigger, and pulls back just to the release: the fault is really only yours if you shoot your foot — or so these folks say.

[Jtsummers]

The problem of C is the success of C. There have been some good, secure, large codebases written in it. Some truly beautiful code, when you scrutinize it.

This creates the illusion that the language itself may be safe, if only you do everything right. That last part is often forgotten by the time people make the decision to write something large in it.

There is no problem with safety nets. Good debuggers (extreme ones like Common Lisp, allowing you to rewrite broken code on the fly and resume from that spot). Good type systems (Ada, the MLs, going so far as to eliminate most errors regarding common mistakes like array-out-of-bound exceptions). Good test suites (comprehensive unit and regression test suites, fuzz testers) which are, admittedly, more pervasive across many languages (the option is available, at least). Formal methods (even the lighter weight ones, like design-by-contract). Automation, to minimize the impact of human error and fat-fingering things. There should be no concern about choosing a language which is semantically closer to your problem domain, but perhaps of slightly reduced performance, than a language that is semantically distant (see people writing half of Prolog into their complex code base involving knowledge bases and decision trees). Maybe some people will think you're not tough enough, but at least your code doesn't piss off every user.

We cannot trust ourselves to do the right thing at all times. Consequently we must decide on the language and environmental elements which can enforce the right thing, while minimizing the impact to developing our solutions in a reasonable amount of time.

[xenadu02]

> There have been some good, secure, large codebases written in it

Citation needed. The only one I'm aware of is SQLite, which has an order-of-magnitude more test code than implementation code and still fuzzers are able to find new memory safety bugs in it.

[eikenberry]

Almost anything by Dan Bernstein might make a good example.

[ergothus]

JS bloat and abuse is very, very real - but the issue isn't JS itself but that the ASKS are bloat and abuse. In contrast with your example, the tool (C) is a bad choice for the job (secure systems). For Web, change the ask and the tool selection may very well change.

I'm a web dev since the 90s, and a JS dev for the last several years. I didn't start in JS, and when I'm asked to do different things I will move away from JS without a major fuss. I use it not because JS is my religious zealotry (though I'm not part of the "cool kids hate JS" club by any measure) but because JS is the least painful way to do what I'm being asked to do. Change what you ask, and I'll change my tool selection.

From this perspective, I don't find your example paralleling the situations to be highly applicable.

[philwelch]

C is more like operating a very large saw without a handguard. If you're skilled and you know what you're doing, you won't cut off your fingers. Which means the median developer cuts off his fingers.

JS (and, more to the point, heavyweight JS framework code) is more like driving a massive SUV around everywhere because you think having to drive through snow and mud is more likely than having to park downtown, when really, all you do is drive around downtown in the summer. But you don't care, because you have a parking valet.

[pjmlp]

We all know how scrutinized Linux and BSD kernel development is and yet CVEs due to memory corruption happen all the time, to the point Kernel safety was the major topic all Linux Security Summit 2018.

If the best aren't able to write safe C what to say about everyone else?

[philwelch]

I wouldn't use a power saw without a handguard, either. But I'm not gonna tell Linus the master carpenter that he can't use his antiquated power saw. Sure, he only has eight fingertips, but he also built the tower we're all standing on right now and continues working on it to this day, so if he's really doing something wrong, the only way to prove it is for someone to get a newfangled power saw, with handguards, and build their own tower. And maybe, someday, someone will do that, and we will look back on the days of poor old Linus and his seven fingertips and wonder.

[Volt]

I don't know of a single person who hasn't made very bad mistakes using C. Even the stuff coming from Bell Labs (Plan 9, UNIX) has had trivially avoidable bugs. By your analogy, everyone has lost at least one digit.

[wwweston]

Really depends on what we talk about as the tool or the problem.

To the extent the claims is "JavaScript the language is the problem"... if somehow Scheme or Python had become the de facto scripting language of the browser in the mid 90s, we'd be having the same conversation. If JavaScript is obliterated by WebAssembly... we'll be having the same conversation (in fact, I predict webassembly -- along with every other effort to treat the browser primarily as nothing more than the universal VM that succeeded -- will exacerbate this problem).

If the conversation is about the fundamental problem of the various incentives to utilize the full computing potential of the browser as a platform even when a document model will do, then "JavaScript" is just shorthand for that since it's the primary language of utilization, and it's pretty easy to realize the tool is the role it fills rather than a specific language.

[TeMPOraL]

I agree and I realize now I need to say this explicitly instead of picking on JS directly.

I thought long about this in the past, and I think JS itself is not a problem - it's just a poor language. The problem is JS + DOM API + CSS + bunch of other things that browsers provide. I feel there's too much creative control allowed for on the web. The language itself matters little; what does is that publishers can shove ridiculous amount of code with little effort, and that the user/publisher balance over control of rendering is so heavily tilted towards the latter.

[watwut]

Majority of new websites dont have big performance problem, at least those I visit.

It seem to me that these debates are happening in alternative universe where all programmers work in well organized companies, withoit deadlines, have time to prototype multiple technologies for all projects and are also all seniors in everything.

In real world, programmers work in chaotic companies with little organization, have short deadlines, have short time to decide which tech, make decision based in what allows them to reach result fast or reliably, are often inexperienced and even experiences seniors don't know everything.

That is how it happens, to the extend there is a problem which author did not managed to convince me of.

[TeMPOraL]

> Majority of new websites dont have big performance problem, at least those I visit.

I'd love to visit that alternative universe. I visit many websites each day, and I could count on my fingers the ones without serious performance problems. HN is fortunately one of them.

> In real world, programmers work in chaotic companies with little organization, have short deadlines, have short time to decide which tech, make decision based in what allows them to reach result fast or reliably, are often inexperienced and even experiences seniors don't know everything.

I know that too well, from experience. It's part of the reason I feel the web needs much less features - as typical companies can't be counted on to use them responsibly.

[yayana]

The majority of new restaurants go out of business, is that an oven problem?

There's some kind of expectations that you can do anything on a website and there will never be reprucussions. Then the blame is so distributed and faultily attributed such that short term results keep the vast number of bad web advisors helping to mishandle more sites. Eventually, a relaunch is done to try to clean out the aggregate of mistakes without getting to the embarrassing root cause analysis.

Not all that different than the restaurant scene in some embarrassing part of the country.

[xg15]

I don't think it's that easy. The product team may vet the performance impact and conclude that the added bloat is an acceptable tradeoff for them against "being able to move faster".

And yet, if everyone is doing that, it leads to a bloated web overall.

[xkcd-sucks]

Sounds a lot like the argument over gun control, but with javascript it's about footgun control

[EB66]

I completely agree with @jbeckham.

The TLDR posted at the top of this article (i.e., there's too much JavaScript on the web) does not line up at all with the problems presented in the article.

The common denominator for poor web experiences is not JavaScript it's not SPAs, and it's not client-side rendering, etc. It's a poorly managed software development life cycle: ill-defined requirements, poorly architected SPAs, not vetting performance impacts, etc.

JavaScript is a victim of its own success. It is more accessible to novices and easier to implement than ever before. It's to be expected that with the growing accessibility should follow a growing number of poorly designed JS-heavy apps.

> as many or more JS-heavy performance disasters cross my desk in an average month as in previous years.

I don't think that's a refutation of JavaScript itself. An abundance of bastardized JS-heavy web apps built by novices doesn't refute the usefulness of JS-driven SPAs and client-side rendering.