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