4 ms·

Javascript is a constant reinvent of the wheel. Sites had become much bigger and much slower contrary to JS crowd promises. Development is a devilish entangleme

Javascript is a constant reinvent of the wheel. Sites had become much bigger and much slower contrary to JS crowd promises. Development is a devilish entanglement of tens of thousands of tiny libraries, and almost every one of them is changing several times a day. I do not do frontend programming now, but I see how slow it became compared to the old good Web 1.0. Monster frameworks that require changing hundreds of files daily, sometimes front development is behind backend development because of this burden and cognitive load. And one fact which annoys me the most: in all other areas we are free to choose any language to do the job. But in the web we're forever stuck with one language which was quickly concocted in a few days and still to this day many of the original flaws remain.

zogrodea 3y ago
I'm not a fan of JS myself in all honesty (just not my favourite language to code in), but I think your first point is more about front-end dev culture than flaws inherent to the language itself. An alternative world could have existed where we have the same exact Javascript, without the culture of using "tens of thousands of tiny libraries" which change "several times a day". It was possible to avoid these faults while still keeping the language itself. So I think it's unfair to say (as the comment you agreed with said) that Javascript is the worst thing to happen to the web, because all the cognitive load being pointed to comes from widespread human usage of the language rather than the language itself. That's on us.
- Dalewyn 3y ago
  Personally, I distinguish the culture of using tens of thousands of frameworks from JavaScript the scripting language by calling it all collectively JavaShit. JavaScript is fine, but JavaShit and everyone who partakes in it are a plague.
patates 3y ago
> Sites had become much bigger and much slower contrary to JS crowd promises Where are those people promising slimmer and faster websites compared to absolute no JS? > Development is a devilish entanglement of tens of thousands of tiny libraries, and almost every one of them is changing several times a day Nothing to do with JS. Many libraries is a symptom of popularity and them being tiny is caused by trying (unsuccessfully though) to send the absolute minimum over the wire. > I see how slow it became compared to the old good Web 1.0. Monster frameworks that require changing hundreds of files daily What web 1.0 was doing is completely different to what the current JS apps are doing. Good luck implementing Figma with the good old web 1.0. I'd even say good luck implementing it anything other than the current web-app dev stack or some custom native UI library which would take a millennia to develop. > sometimes front development is behind backend development because of this burden and cognitive load backend and frontend dev have completely different constraints. Doing frontend dev for a native app is also cognitively nearly completely different monster. > in all other areas we are free to choose any language to do the job. But in the web we're forever stuck with one language I mean you could always compile to JS and these days there are many good webassembly frameworks. > still to this day many of the original flaws remain But also almost always easy to avoid. It's a necessary evil for backward compatibility.
- zelphirkalt 3y ago
  > Where are those people promising slimmer and faster websites compared to absolute no JS? The crowd that claims, that reloading the page is bad and therefore there must be JS involved to only generate parts of the page dynamically. > Nothing to do with JS. Many libraries is a symptom of popularity and them being tiny is caused by trying (unsuccessfully though) to send the absolute minimum over the wire. I think it does have to do with JS: JS did not offer much. Many things were missing. Other things were so bad, that people build abstraction layers on top, to hide the uglyness of JS underneath and then published those layers as libraries. So the language itself has at the very least historically directly contributed to the current state of affairs of thousands of mini libraries. Even JS developers themselves don't trust JS or their own ability to work around JS' quirks, so they include left pad and other funny things. > What web 1.0 was doing is completely different to what the current JS apps are doing. Good luck implementing Figma with the good old web 1.0. I'd even say good luck implementing it anything other than the current web-app dev stack or some custom native UI library which would take a millennia to develop. Not the GP, but I am also against the Figma pipe dream designs being pushed onto the frontend developer. In my opinion a good web designer should know CSS well and know the implications of their design ideas before pushing them onto others. Want to make a design that has something, that is difficult to achieve without JS? Better think 5 times about whether you really need it and whether that design addresses fundamental functionality of the website. > But also almost always easy to avoid. It's a necessary evil for backward compatibility. Only by writing code you usually would not have to write in other language, to plaster over JS' faults, or by including lots of tiny libraries as dependencies, dooming your project in the long run.

zogrodea 3y ago

I'm not a fan of JS myself in all honesty (just not my favourite language to code in), but I think your first point is more about front-end dev culture than flaws inherent to the language itself. An alternative world could have existed where we have the same exact Javascript, without the culture of using "tens of thousands of tiny libraries" which change "several times a day". It was possible to avoid these faults while still keeping the language itself. So I think it's unfair to say (as the comment you agreed with said) that Javascript is the worst thing to happen to the web, because all the cognitive load being pointed to comes from widespread human usage of the language rather than the language itself. That's on us.

Dalewyn 3y ago
Personally, I distinguish the culture of using tens of thousands of frameworks from JavaScript the scripting language by calling it all collectively JavaShit. JavaScript is fine, but JavaShit and everyone who partakes in it are a plague.

patates 3y ago

> Sites had become much bigger and much slower contrary to JS crowd promises Where are those people promising slimmer and faster websites compared to absolute no JS? > Development is a devilish entanglement of tens of thousands of tiny libraries, and almost every one of them is changing several times a day Nothing to do with JS. Many libraries is a symptom of popularity and them being tiny is caused by trying (unsuccessfully though) to send the absolute minimum over the wire. > I see how slow it became compared to the old good Web 1.0. Monster frameworks that require changing hundreds of files daily What web 1.0 was doing is completely different to what the current JS apps are doing. Good luck implementing Figma with the good old web 1.0. I'd even say good luck implementing it anything other than the current web-app dev stack or some custom native UI library which would take a millennia to develop. > sometimes front development is behind backend development because of this burden and cognitive load backend and frontend dev have completely different constraints. Doing frontend dev for a native app is also cognitively nearly completely different monster. > in all other areas we are free to choose any language to do the job. But in the web we're forever stuck with one language I mean you could always compile to JS and these days there are many good webassembly frameworks. > still to this day many of the original flaws remain But also almost always easy to avoid. It's a necessary evil for backward compatibility.

zelphirkalt 3y ago
> Where are those people promising slimmer and faster websites compared to absolute no JS? The crowd that claims, that reloading the page is bad and therefore there must be JS involved to only generate parts of the page dynamically. > Nothing to do with JS. Many libraries is a symptom of popularity and them being tiny is caused by trying (unsuccessfully though) to send the absolute minimum over the wire. I think it does have to do with JS: JS did not offer much. Many things were missing. Other things were so bad, that people build abstraction layers on top, to hide the uglyness of JS underneath and then published those layers as libraries. So the language itself has at the very least historically directly contributed to the current state of affairs of thousands of mini libraries. Even JS developers themselves don't trust JS or their own ability to work around JS' quirks, so they include left pad and other funny things. > What web 1.0 was doing is completely different to what the current JS apps are doing. Good luck implementing Figma with the good old web 1.0. I'd even say good luck implementing it anything other than the current web-app dev stack or some custom native UI library which would take a millennia to develop. Not the GP, but I am also against the Figma pipe dream designs being pushed onto the frontend developer. In my opinion a good web designer should know CSS well and know the implications of their design ideas before pushing them onto others. Want to make a design that has something, that is difficult to achieve without JS? Better think 5 times about whether you really need it and whether that design addresses fundamental functionality of the website. > But also almost always easy to avoid. It's a necessary evil for backward compatibility. Only by writing code you usually would not have to write in other language, to plaster over JS' faults, or by including lots of tiny libraries as dependencies, dooming your project in the long run.