Formally-Trained WebDevs, why do you use so much Javascript and WebAssembly?

[Dreamwings]

Since there is a good mix of self-taught devs and formally-trained devs here, massive question I have always wanted to ask....
Why do you use so much Javascript and WebAssembly?

Of course it makes sense for corperate sites to use so much JS, since they are doing all of their shennanigans, but even outside of that, a lot of indiependant sites created by those formally-trained in webdev in college and such rely heavily on bloated JS and libraries for things that could just be done with fewer lines, basic JS, no libraries, HTML and PHP for a far more compatible, lighter, and performance friendly experience with both old and new browsers (after all, the consumer/person on the other end might have a weaker machine that can't run the most modern, shiny browser on the market or maybe they're me who don't want to). A common thing I see for example is using Javascript to load images. I think it might be for multiresolutions (ie, if screen is zoomed in at a certain amount it doesn't load the highest quality version immidiately), but it's either have the multiresolution code or have large performance-browsers/people who refuse to run javascript loose the ability to load images entirely. Do you even need multiresolution code when jpegs are still amazing? (seriously. I know people dog on them for quality loss but they can stil get what would be a 4mb file down to only a few KB without THAT much quality loss. And that quality loss can easily be fixed with a press of a button in 2024.) Or if jpegs aren't your forte, webps (They're annoying but they are genuinly amazing when it comes to compression. Especially of the animated variety in comparison to gifs).

My guess is it is just the way it is taught and it's hard to unlearn the formal education you recieved, plus its easier to just type one command/fewer commands vs multiple to do the same process, but I am still curious to hear it from the horses mouth.

[brisray]

Although they have vastly improved over the years, there's only so much you can do with plain HTML and CSS. JavaScript helps but that's front-end, relying on the vistor's computer and browser to work. The back-end, connecting to databases and so on depended mainly on three languages, Perl, Python and the most popular, PHP.

Over time, it was decided that instead of writing everything from scratch, why not use standard frameworks. One of the first for JavaScript was JQuery which was great. Then others were developed until now there are about 30 of them. Apart from functionality, ease of use and saving time in development, the idea behind the framworks is that everything looks the same no matter what operating system or browser a visitor is using.

In industry, what actually gets used is usually decided by just a couple of people; managers and project leaders. Once it's decided which to use then it becomes difficult not to use them for everything. In education, apart from professors teaching what they are used to, they try and make the students employable, that means teaching whatever is popular in the industry at the moment.

Years ago, I worked a place that just worked on databases, that's what we did all day, everyday. It became part of my job to train people straight out of college. One of the first things I told them was to forget anything specialized they were taught. This is how we work, this is what you are expected to use, and these are the standards we expect you to work to. It had to be that way because we were processing other companies databases. A mess up meant we would get sued, and we did several times because someone did something they shouldn't of and our testing couldn't pick it up before it was sent back to the owner. Webdevs have different pressures, someone wants a website to look and behave a certain way and it's usually quicker and easier to use a framework to do it.

Then there are the Content Management Systems (CMSs). The last place I worked used a bespoke version of Drupal. Over 5,000 lines of CSS, two JavaScript libraries, all the PHP it used and whatever Drupal added meant a page was approaching 1Mb before the content was even written - and that was usually a bit of text and a few images.

For my own hobby sites, I moved away from all of that and use the absolute minimum I can get away with. The CSS is less than 8Kb, under 5 when it is minified and even less once it's gzipped for delivery. The JS file (just plain JS, no framework), is 3Kb, and around 2 when minified. Not every page needs the JS, and some use a little more CSS and JS, but that is loaded separately.

[ajazz]

the short answer is that the developer experience was, for a time, way better than the alternative.

if you know how to code, modern js frameworks just absolutely blow the DX of the previous options out of the water. i remember using django back in the day and i am happy to never go back

however, you're right on the merits - there's way too much bloat and js in our sites, and most professional webdevs are very aware of this. now, new frameworks will advertise themselves by how little js they use, rather than how much. personally, i use astro for every frontend project i can, and the reason that i love it is because it's the perfect compromise between the pure-javascript SPA workflow and the older way (template languages etc.) of doing things. it ships zero js by default, but it gives you the option to use basically any js framework you want for individual components, and it handles the image optimization with very little extra effort. i can happily recommend it to anyone who wants a convenient modern workflow without a ton of bloat

[kurohaato]

Personally, there's just some things I'm more comfortable doing with JS. I try not to go overboard but depending on what I'm doing it's more convenient for me to write some JS instead of endlessly copy and pasting html elements over and over and then writing JS anyway because I need to make those HTML elements actually do stuff because the stuff I want it to do isn't supported in HTML. Besides, I need the practice and it's not like my site's completely inaccessible without the JavaScript.