4 ms·
> 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
by 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.