How JavaScript Ruined the Web 

Then you see all the chuckleheads that say you should just buy a newer computer. What a wasteful mentality.

we should let people choose whether they want the fastest version of the site possible or the regular one

@@BusinessWolf1 Gmail used to have a basic HTML version that dumped all the fancy interactions for the sake of low spec PCs. Sadly, I doubt most modern sites are designed to be able to dump the heaps of JavaScript wiring them together.

​@@AROAH The problem is that it's expensive to host Server Side Rendered (SSR) Website and that's why a lot of companies are moving away from it, now they just host the static files & the api. But frameworks like SvelteKit are built for the middle ground where it prerender a static page, SSR the first request & handles the reactivity using JavaScript without virtual dom like React.

2gb in 2016 was still pretty bad

the worst of both worlds

Imagine a web browser written in Electron loading modern websites with heavy JS frameworks like react.

@@TheExileFox Just like hell

Yes, but some - like VS Code - can be quite polished. Slack, bashed by everyone as a memory hog, is ok too.

@@n1vz3r VS Code was written entirely with vanilla JS, so it is extremely well optimized, for an Electron app

when he only knows js.

Yeah, but that doesn't make the cycle of "keep using more bloated frameworks until the site is impossible to maintain, then tear it down just enough to make it possible to develop again" a good thing. That mindset costs companies literally billions of dollars a year and is objectively worse long-term compared to the future we could have if we put in the work to transition web development to a more responsible language/ecosystem like Rust. Everything would be far easier to maintain, breaking changes would be rare, large projects would be easy to understand, the benefits go on and on. Move fast and break things is probably the worst project paradigm around, because it makes sense from a standpoint of trying to attract venture capital, yet it's used on massive projects that will still be in service in a decade.

as a C programmer who actually develop Drivers and do Kernel stuff. I agree with you lol. I have a personal project that did require lots of javascript (it is similar to Reddit) but I did it 100% single page, client rendered using websockets. Did it with regular javascript, everything by hand, no angular, no vue, no react.

​@@DLainExactly, you can build apps without using frameworks at all. In fact, my apps are faster this way

​@@kylehart8829it costs companies billions, what does that mean? What I hear is, it forces financial interests to employ a work force. Efficient for a financial interest means they keep the money and spend less on the actual work force. Saving what and for whom?

" You don't necessarily care about the performance, accessibility etc (unless explicitly defined in project requirements)." This is a systemic problem of unprofessional lack of responsibility in web development that justifies that bloat or ignorance on part of the client. Especially with factors like accessibility which can have very real legal consequences. Thing about in what other industries is behaviors found in web development acceptable. Could a car builder just leave out safety features like seatbelts or have a slow engine because it's not in the spec. Imagine a lawyer not required to inform their client of some legal jeopardy because the client didn't request to be informed of the law.

maybe webasm will allow native performance scripting in arbitrary languages, but that sounds too good to be true.

That's just your point of view because you didn't use JS Frameworks. Let me assure you that those framework e.g. React are more optimized than you vanillaJS code because those are actually compiled into vanillaJS, minified, optimized and bundled into small parts before they are sent to the user's web browser 😅

@@julianojosoa2145 meanwhile reality proves you wrong

@@julianojosoa2145 Here's the thing. It's literally faster to refresh the whole page than to do the whole retained mode nonsense. Go to some professor's webpage which are usually pure html+css. Click on links. It's _instant._ Bringing in a bloated mess like react to avoid refreshing the whole screens is just bonzo.

@@julianojosoa2145 Here's the thing. It's literally faster to refresh the whole page than to do the whole retained mode nonsense. Go to some professor's webpage which are usually pure html+css. Click on links. It's _instant._ Bringing in a bloated mess like react just to avoid full screen refresh is bonzo.

Unless your project uses JS for minimal interactivity and css manipulation, going on JS alone is a very bad decision.

@@GeneraluStelaru Nope, the only sane decision.

What I also like are frameworks that compile to vanilla JS and CSS, like Svelte. You get cleaner, more structured code with less boilerplate while developing, but then compile it to an optimized bundle. But I do have to agree that vanilla JS and CSS are more than enough for many sites.

@@GeneraluStelaru yes. you would only end up creating your own framework. people who want to build entire interactive web-apps without a framework just end up writing bad code, or their own version of a framework. which, would be ok, if it wouldnt consume a huge amount of time and energy. the problem are not webapps, its a big marketing teams, overloading adds. slow APIs. bad infrastructure. maybe a bad mix of SPA on a api designed for a MPA etc. etc. its not "vue's" fault! its the fault of many aspects not working well together and, as a result, creating a bad website which everyone seems to hate :D

Fuck frameworks. We programming in binary now.

What I find hilarious is that people act like SPAs are "more efficient" because you don't need to keep loading new pages all the time. My brother in Christ, now you need the whole goddamn website loaded in RAM right from the start, mobile data through the roof, the web was paginated for a reason and loading pages takes 0.1 second each. Stupidest aspect of the modern web.

Bring on the era of WebAssembly I guess

​@@colbyboucher6391 If I may play devil's advocate, the idea is that the program is usually smaller than the data. You're not loading the entire contents of the server's hard drive, you're loading components that specify how to display and interact with data. That data is usually loaded on demand through xhr requests or the fetch api. It just so happens that most frameworks are so dependency heavy, the assumption that program size < data size might not hold up well on the modern web. With React, you as an end user have to load the entire React framework from one of Meta's CDN servers. With something like Svelte, on the other hand, it's all compiled down so the end user only has to load a relatively small script with not much more than the page developer's actual logic, even though the developer needs hundreds of MB of dependencies to generate that smaller file. The overhead of the framework itself to the end user is in the single digit kB range. But it's really all the ads and trackers that slow things down more than anything else. Web assembly is great in many ways, but it can't touch the DOM. It still has to go through javascript to actually do anything, or whatever hosting environment is embedding it. I love it as an open standard for a VM to use in lieu of things like Java or .NET, but on an actual web page its only advantage is computing power for raw number crunching, or bringing old legacy native programs onto the web, not so much in the reactive UI department. Blazor, for example, needs a couple MB of code just to bootstrap .NET in a WASM environment. Rust and C with emscripten fare a little better at 100-200 kB, and a raw Rust or C wasm module with no support layer takes barely anything beyond the actual functions you write. So while the performance is not an advantage in the UI case, it does allow development in other languages besides Javascript, which is a plus all by itself.

"Major problems: Nobody is really doing things data driven, nobody cares about underpowered devices, nobody cares about data limits, " Which is why I believe regulation of soft-dev or web-dev will happen in our lifetime. At least in the case of accessibility there are very defined legal consequences that can force businesses to care.

@@TheNewton I couldn't advocate for legally regulating web development in this sense because the definition of "old device" is constantly in flux, and lawmakers are notoriously bad when it comes to ever evolving tech. Additionally, there's an argument that this would stifle innovation from companies trying to do new things as there's now a business overhead associated with this kind of regulation. If you want to legally force old device support then you can say goodbye to using emerging / semi-mainstream technologies such as WebAssembly (ruling out anything made using Microsoft's Blazor, for example). If there is such a regulation ever proposed, this is why I believe that the political tech lobbyists would never stand for it.

I think it's still using mostly Javascript. It's a compiler, but it's compiling to Javascript, not HTML

@@michawhite7613 svelte defaults to sveltekit (nextjs/gatsby alternative) that renders server-side.

@@tehmaid Server-side rendering is better but my understanding is that it creates a string with the needed HTML and then uses JavaScript to insert the HTML into the page. That's at least what the Svelte playground seems to suggest.

​@@michawhite7613 Server-side rendering means that the end user gets pre-rendered HTML. In SSR most of the page is rendered statically and then client components add interactive functionality, or you can implement an entirely static HTML page. In sveltekit for this you would have to enable prerender and disable hydration. You as a developer write in javascript and it does need a compiler that would compile your server components to HTML, but the result will be a page that contains no javascript runtime AT ALL.

100% with you - Svelte and SvelteKit but only for data driven applications, i.e. where pages or part of the pages depend on data that are best stored in databases or need true interactivity (zooming into maps, graphs, gaming interaction etc). For purely static sites I would most likely go with static HTML and CSS. However, as soon as you have some consistent navigation framework or so, SvelteKit's routing layout and page concept can be super valuable, as an alternative to PHP or other server side dynamic code.

One of the bloated sites that he showed off was New York Times and they don’t even use a framework they use Wordpress which is a cms. Not to say that it is a very big deal, everyone makes mistakes but I’m still triggered :

Gatsby IS React. It's just a framework like Next

Svelte is simpler to use and faster

​@@rimondas6729and you will never get a job with it

The only fast websites are the ones who are not bloated. Bloat is inversely proportional to speed.

And here is me, who is so self conscious even when adding google fonts as a single dependency on my site.

That was me with Angular for the first time. "200 MB for Hello World?! This is ridiculous!" Of course a lot of the packages can be installed globally, so you don't need another 250 MB for every project. If you think about it, you're basically downloading a compiler for a new language, in source code form. Still, it's kind of crazy how many dependencies there are. "Don't reinvent the wheel" has turned into "Build a car by buying every part from a separate vendor." ... and then my package manager breaks because i ran "sudo npm update" ...

Node has HTTP server built in and there are more smaller packages for simple stuff Express alternatives like Hono.

I wonder if you would find it less wrong to parse the response stream manually, then?

But packages are necessary

This. It feels to me that using hammer for everything is a trend now, and you'd use a modified hammer to open screws.

Agree, but Ive always had a problem with js. Now vue is half of my day job and a quarter of my desktop software was written in js.what a world.

Literally website on Neocities are better than the crap people make professionally now. Nothing gained whatsoever.

I've been doing a lot of work to optimize my company's login page, and I'm starting to get to the point where there's more kilobytes dedicated to analytics than to the page. God help me in convincing the team to let me get rid of analytics.

The biggest issue is JS and SPAs moving more HTML generation to front end frameworks, so now your clients (phones, personal PCs) have to load more framework code instead of keeping it in the servers. The old MVC framework model typically generated the views in the server. It's especially a problem with bandwidth throttled situations you loads feel as slow as the older days of the web with 56k modems and you're simply loading a text article and a few pictures.

Old web, but with AVIF, AV1/HEVC, OPUS/OGG... Yeah, that sounds cool. We can significantly boost it's quality!

"Reactful" "Stateful" "Functional" (the buzzword not the paradigm)

I think you forgot to add tracking

getting things for free means getting much more crap with it as punishment for not paying

Sites suck because an industry web-dev is severely lacking in professional rigor that knows how to say no to clients fumbling their own business interests.

@@TheNewtonagreed

1. An explanation why some websites have dark mode flicker is a when the user selects the "System" option when choosing a theme. The system option automatically follows the user device's color theme and can only be applied by JS when the actual website has loaded. Before the website loads, it will appear in its default theme (usually white) which causes an unavoidable flicker. And yes, this is unavoidable even in a pure SSR or static website. 2. Yes, animations are surprisingly good for increasing your product's value.

​@@okie9025you can solve this on SSR, you can save the theme as a cookie and apply it server side

@@okie9025 That's not true, and I don't see the point in repeating what I said in the previous comment.

@@okie9025 CSS has a "prefers-color-scheme" media query, that should resolve immediately before the page is rendered. A script could overwrite that with its own logic, but flickering before going dark is not an inherent part of how the web is designed.

A comment on the animations on the web: It's there for those who appreciates the presentation, especially on the kinds of websites that are trying to be artsy-ish. The animations bring something unique to the idea you're standing behind, whether it's for an art project, or your portfolio. To quote a comment of my past mentor: "The Web doesn't necessarily have to be fast and optimized, as long as you are satisfied with what you believe in." As for dark mode, most of the time it's a fancy version of "Telling JS to add some class to some CSS somewhere", with additional project architect complexity. That's how I see it through all of my past projects that touched upon this matter.

Just a tip vaguely related, if your mouse has 2 extra buttons you can use them to go back and forth pages, and it works everywhere, files, vscode, browser i have yet to find a place that for some reason doesn't support this

@@furinick You see, those extra buttons go back one entry, not multiple entries at once, whereas with the right-click, you can go up to 6 entries back at once.

If you use nvm and keep your packages locked to specific versions, can always go back !

@@mattmmilli8287 A solution for a problem that did not need to be there in the first place.

​@@MadsonOnTheWebcare to elaborate? I don't see anything wrong with that.

PHP has come a long way. Updates makes sense unlike many other languages

It lacks a pdf download , though gets points for having downloadable zips and chms files.

I barely fathom how that works but sounds cool as a solution

they try hard to choke themselves to death building next floors to a tower with too unstable foundation not seeing the problem is the whole tower itself and making it standard they keep everyone a hostage of this as companies hate to rewrite anything and start fresh in different technology things in js world grow like cancer cells and instead of healing they decide to live with multiple sicknesses calling them not system error but features

i honestly don't think ebay even needs javascript for most of its pages

At least, we have now Vite 😀

😂😂

Yeah internals documentation is always severely lacking and hopping through them in a debugger is always a mess to mentally untangle.

Yes, I agree. I am old enough to remember remember when performance not ease of use was the hallmark of software.

dark, light, black theme switcher is like 50 lines of JS code, site independent, just copy it attach to your button and that's it, I never used frameworks, am I crazy or what?

@@JamesSmith-ix5jd depends on the person and especially browser support, if you want IE etc, im no web dev but i know many web dev should stay far away from code

I was also thinking of building my own website with Astro, it feels like the balanced way to go about this. Static by default, interactivity is added when needed, and different paradigms of rendering depending on need. Basically, opt in complexity instead of "required" initial complexity.

Really hope for better client side routing for the future. Server site routing feels weird and extremely slow.

That sounds like you fell for marketing talk. If there's another step before payload is displayed, then it's not a static page at all. Whether it's called "hydration" or something else is irrelevant. Another framework that is part of the problem. If you want the solution, get rid of frameworks entirely!

@@Alien426 Not sure what you are arguing against here... I said that the initial paint is very fast, but that TTI can be sluggish. And don't worry.. I havn't fallen for any marketing talk. I'm speaking from years of trial and error as a frontend developer. In fact I really dislike Gatsby because it's bloated and build times are really bad. All I'm saying is that most of html is served on the first fetch unlike Create React App for example.

...and that the first fetch will be very fast since it's serving a static site, meaning it's actual static .html + .css files on the server, not server side generated markup.

He doesn't think, this is a rant out of a bad faith argument.

it is faster because you don't write anything you just import a ton of libraries and pray that they don't explode one day. Actually C/C++ are not that different, let's say you wrote something in Qt4, then didn't maintain it for a decade, will it compile today? of course not.

@@JamesSmith-ix5jd EDIT EDIT: Sry inb4. I wrote a longer comment then i expected. I just cut around 50% of my previous comment The amount of libraries you use in C++ usually isn't even close to as bloated as the Javascript libraries i had to use (usually with a few exceptions such as game dev). With C and C++ it is often more important to know your standards when using most libraries. But yes, you are right that time will also be an issue there, specially when the operating system changed a lot through updates (In Linux case) or through newer versions of the OS (Windows case). And both makes compilation harder when you did not store the libraries somewhere. Though C/C++ is less dependant on changing standards then JS when you run it in the browser. my issue is also not writing. Yes, you are faster there with frameworks. But my point was the processing power, which i think a web application suffers way more from then a natively run application. Specially when it comes to network stuff i think the bloat should be a bit cut down since most people in the world have slow connections. (Including me a few months ago since i live in a village) EDIT: I want to clarify since i think i phrased it badly when i read it again, i do not say there are no bloated libs in C/C++. And specially in game dev or other graphics stuff there are heavy weights out there. However i didn't work with as many there as with Javascript since it seems many sites rely on it. Also running a program natively on a machine or through the web makes a huge difference in processing stuff. That is why my focus also was more on JS. I personally never worked with Qt though. I can't tell there much but due to the nature of this API, yes. I think it can have similar issues.

All the people I see complain about programming or Frameworks in general never worked on a big project. You never really understand how good/bad/easy/hard something is unless u do it big. I have a fairly large react codebase that Is a rewrite from using plain js, it is MUCH better both from DX standpoint and performance/UI UX.

@@specy_ Its better for ur usecase. Wont be a universal better solution

Devs add a shitton of ads and trackers, use the wrong tools and write overall bad inperformant code - RU-vidr: 'react makes website slow'

@@moritzschuessler ofc, the use case is having a big project, which a framework makes way easier

Literally the first piece of react code he shows is in TS

Java is for the backend, JavaScript for the frontend (mainly). So it depends on what you want to do. Personally, I'd strongly recommend learning accessibility, SEO and WAI-ARIA guidelines if you're looking to focus on the frontend!

continue learning your way to javascript, that three is the standard things in web dev. html css javascript.

You can't really do webdev without js, I'd focus on that first, then java

There is no finish, just a shift in focus. All of this stuff is constantly changing. I'd probably do some back end stuff at the same time, even if it's just barely enough for your front end to send requests to. Or set up Postman to respond. Options to pick from: Front-end htmx JS Solid or Svelte or Vue React (yuck) Back-end Node (bonus, it's also JS) C# (yuck) Php (people hate on it, but I like it) Or take a detour. Take a couple days to do some client side form validation for both US and Canadian postal codes, or phone numbers, using the pattern attribute. Regex are amazing.

You pretty much added more value that the video. Bashing on frameworks that was used without real reason since plain HTML and CSS would be fine, is dumb. Same as using a million trackers and ads and then bashing JS for it is equally dumb

Reminds me of Molly Rocket or Jon Blow talking about performance in modern software.

@@DFPercush Yes exactly and I think they're right on! It's nice to hear it from career developers, since in my experience a lot of developers care so little about performance.... Actually that's not really fair, most PEOPLE don't seem to care about performance anymore. Everything is slow now. Processors are hundreds or even thousands of times faster than they were a couple decades ago, yet software is slower. It's awful. But the web is a special kind of awful. Not only is it SLOW, but it's overly interactive. Sounds counter-intuitive, but I don't want autoplay videos following me down the page, newsletter popups, sites that rearrange themselves as they load, constant mouse-over events etc. Seriously I was around back in the 90s and early 2000s when the internet was popup + GIF central, and I honestly think the web is WORSE now than it was then! And that's really saying something. OK rant over heh

@@PwnySlaystation01 Yeah, it's crazy how hard the chip manufacturers have worked to enable us lazy developers to say "good enough" and ship slow but "passable" garbage. Don't get me wrong, I'm glad I don't have to count every cycle and pull clever hardware hacks out of a hat like early game developers on something like the Atari or NES, but a basic sense of what your hardware can do and what makes things slow goes a long way. If you think about it, the web was originally designed as a document delivery system, not an application runtime. If the browser was intended to be a thin client for a full application stack, I think the protocols would look a lot different. Having that capability is frankly very nice, it allows people to use services without downloading and installing suspicious .exe files, and share stuff, and all that, but it gets really annoying if all you're expecting is a document.

@@DFPercush Yeah the browser is essentially an operating system at this point. Just in general, I do worry that we've abstracted so far away from the hardware that there are maybe two generations of developers who genuinely don't know how the hardware actually works. Like they have a vague, super-simplified idea, but couldn't really tell you how their code actually gets executed on the CPU. I'm worried that when the old timers are gone, nobody who writes programs will know what their programs are really doing anymore. Game development (more specifically, engine development) is one of the VERY few areas where a relatively deep understanding of the hardware is still valued. It's like, compiler developers, game engine developers and super niche ultra-performant developers ie: financial trading systems etc.

chrome will put your old pc on the knees anyway, what's the point of optimizing the site

HTMX is so great and easy to use

how canvas works in it?

@@szymonbaranowski8184 any HTML should work fine.

to make something fast best tip is to limit steps something needs to give output but limiting things to show works also we forgot all magic from early days of internet when with small simple things you could build huge effect

@@szymonbaranowski8184 I did code my first website and the only time it uses is when It first needs to check if the user is on mobile so it can redirect them to the mobile page and the other is a button to change the page to Dark mode ot Light Mode.

⁠@@confusinggameplays1687why make a mobile page when u just can make it responsive with CSS Media queries?

Sparta limited everything not for sake of minimalism but to maximize core points to legendary level and they also cheated a lot😂

@@szymonbaranowski8184 wat

feels a little clickbaity

i would add another thing that ruined web. Its a shit ton of trackers and add that are intentional used. Even most of the examples used here wasnt bad because of bad devs or react. Its just the trackers and ads. Use a ad-blocker and block trackers and all of these horrible newspaper and recipe sites will be fine

@@moritzschuessler Yeah, even tracking cookies that auto recreate themselves exist, I don't know if those are possible anymore.

Yes, you should load the JavaScript after the HTML, but some JS frameworks initially ship no HTML to the browser and render it all dynamically with the JS framework, which causes issues

@@JamesSmith-ix5jd Is that true? I think it actually is better performing than JS.

I've really enjoyed using blazor, it works pretty great.

Do you really think that other languages won’t be fucked when loading 10m trackers + a shot ton of ads?

​@@JamesSmith-ix5jd WASM is complied to binary and then executed by the host in a sandboxed environment. It is important to note that yes the browser is managing the overall sandbox but WASM manages to bypass the need for an interpreter. This does lead to significantly more efficient execution.

​@@mosch1811 Its totally possible. But if someone has already gone to the length to use a more efficient execution in another language, it would not really be in line with their strategy to then bog down what they are serving with bloat from trackers. Additionally I think developers need to stop indulging bad behavior.