How JavaScript Ruined the Web
HTML-код
- Опубликовано: 10 июн 2024
- Ever noticed how bad the modern web is getting? Why is every website a slow, laggy, buggy mess? Whatever happened to the good old days, when websites were simpler? In this video, I'll talk about how the rise of JavaScript frameworks like React have been a disaster for the internet...
🌐 My website: ericmurphy.xyz
💸 Support the Channel: ericmurphy.xyz/donate
🎥 Watch my videos on Odysee: odysee.com/@ericnmurphy
💻 My GitHub: github.com/ericmurphyxyz
0:00 The absolute state of the modern web
0:45 The JavaScript obsession
2:57 Peer pressure
4:31 The FUTURE of web development!
6:20 Move fast and break things
7:59 Muh "Developer Experience"
9:53 Peak performance
11:36 The user "experience"
12:16 How to make non-bloated websites
14:17 Conclusion 
Наука
![Latto - Sunday Service (feat. Megan Thee Stallion & Flo Milli) [Remix] (Official Video)](http://i.ytimg.com/vi/9gL0F1xIt2I/mqdefault.jpg)
I remember when I got my grandma a Chromebook with 2GB of RAM back in, like, 2016. I thought there was no way she’d need anything better than that with just web browsing. Fast forward to now, where a single Facebook tab can choke that Chromebook’s resources.
What a world.
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
There's something worse: Electron Apps.
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
"Hey, can you please change that link on our website?"
"Sorry, that's gonna take some time, gotta find it in the code"
??? HUH ???
this actually happened.
when he only knows js.
I'd respond with:
Oh, so you don't know how.
That's alright, I got it.
As developers we generally work on two types of projects: One type of project is a contract work for someone else, another type is a personal project (hobby, your own app etc). The contract projects are the ones where development speed takes precedence over everything else. You need to churn out the project as soon as possible so you can work on other projects. These project you have to show to the client, who is easily impressed by the gimmicks (spa, animations, "analytics" etc). You don't necessarily care about the performance, accessibility etc (unless explicitly defined in project requirements). The other type of project is personal project. Now these are the projects you handcraft to be the most optimized and beautiful. Here You wouldn't (and shouldn't) use bootstrap to style a button in your page (hence adding the bloat of libs). In these projects its a good idea to build everything by hand because its a nice learning experience. You would do this because the sole developer is you on your project (or you maybe have an intern who you can easily teach), however on contract projects you have to use a popular framework so your client can get it developed further if desired. You can expect another developer to know me-3 p-1 classes, but not just-the-right-amount-of-padding-and-margin class.
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.
It's a complicated problem because indeed not knowing React or Vue today is a major hinderance to your career as a developer and you'll struggle to find work that does not require production experience with these frameworks. This alone already motivates people to use frameworks for everything
At the same time yes like most things development often chases trends rather than focusing on objective data driven decision making.
The more javascript you add to something the more problems you're creating... more libraries means more time spent debugging other people's code.
Major problems: Nobody is really doing things data driven, nobody cares about underpowered devices, nobody cares about data limits, nobody cares about acessibility, mobile web development is still an afterthought. And so in many ways webdevelopment took 1 step forward and 2 steps back and lost track of what the ultimate goal is
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'm originally a C++ dev but at my last job had to take over a few web projects and I didn't want to learn React so I wrote them in native JS, which at first felt wrong because the way people talk that is an outdated way of doing things, but slowly over time I realized my web apps were way faster than any of the ones people with frameworks were making. The thing is it's tempting cause a lot of them have cool functionalitt built in but it almost always bloats what you're building and people don't seem to consider this and just default to it
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.
Vanilla JS and CSS have come along way these past few years and are only getting better. It would be nice to eliminate frameworks altogether, but that's not going to happen.
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.
In my experience it's not just frameworks - it's tracking libraries and a ton of 3rd party libraries stacking on top of each other
Svelte is one of my favorite JavaScript frameworks and the main reason for that is that it has an amazing feature that lets you export to raw CSS and HTML without any JavaScript at all
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.
I remember when I first tried using Node and use express to make a simple server, the moment I saw 100 packages download I knew there was something wrong.
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
My internet isnt the best. Modern internet had even the simplest of pages take far too bloody long to load.
I’ve never used gatsby, but I have used React for years. I built my personal website using Next my website is incredibly fast. It loads nearly 0 JavaScript because the HTML is generated at build time. There’s plenty of ways to leverage the power of react, and still deliver fast websites. The problem isn’t the tools, it’s the developers who don’t know what they’re doing
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.
With the advent of "no JS by default" frameworks, I always wonder: if your site doesn't need JS to function, why are you even using JS? IMO JS is specifically for interactivity, and using it for that purpose is fine and dandy. It becomes really tricky when it replaces the server, the data backend and the markup for the frontend, usually also tying you to various AWS reseller's products indefinitely, cause even if they say it "doesn't lock you in", you know damn well it makes it difficult to move away from.
This. It feels to me that using hammer for everything is a trend now, and you'd use a modified hammer to open screws.
I've never had a problem with JavaScript as a language. But needless bloat, JS just to load HTML and CSS, and the worst of all... spooky trackers all on the client side is just a cancer that is taking over the web. As web devs we need to go back to the simpler days but combine it with the good innovations of today. Thanks for this awesome video, subscribed and you know I hit that damn notification bell
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!
That's why, when you're in a slightly worse (but still in) cellular coverage area, you could also be completely offline, because nothing will load.
Yes, I'm tired of all the tools and build steps of modern frameworks.
FINALLY someone talks about this. I thought I was going insane with everyone overusing JS frameworks because "it's the new thing" and that I will "become obsolete" if I don't.
I just let HTML do HTML things and JS do JS things. And it's so damn fast and light.
"Reactful"
"Stateful"
"Functional" (the buzzword not the paradigm)
The part about breaking things is so true. I build a newspaper website 2 years ago. Tried to perform maintenance on of these days, and it would not even run due to hundreds of dependencies that had breaking changes. I really mean hundreds.
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.
If I weren't "forced" to use React since that's what the project I'm employed to work on is using; I would definitely prefer plain JS and actual page loads for most of the stuff I'm working on.
But annoyingly and somewhat ironically; while the massive bloat of the ReactDOM is unavoidable with react; and a few 3rd party JS dependencies that somehow always includes everything no matter how I try to code split; a much bigger issue on the website I work on is actually overly high res pictures and absurdly long content; plus and all that nonsense that is injected by the analytics team with massive scripts from at least 3 different analytics providers (that of course does not have proper cache headers that Google lighthouse complain about despite 2 of those libraries with incorrect cache headers are from Google!!!) and the A/B testing scripts that also are super heavy, causes layout shifts and REGULARLY breaks things because it's a script written by analytics experts that have no React experience directly manipulating the real DOM which messes up React components a lot.
I completely agree with everything you say. I also don't understand what is going on on some websites when toggling dark mode and the page seems to be doing some heavy stuff while the screen flickers. And all JS should do is add a 'dark' class and store the user's preference. The rest is done with CSS, even to determine the user's OS theme settings.
I also don't understand the purpose of most animations on modern websites, is it really that pleasing to end-users? People should really care more about things like accessibility and performance.
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.
Honestly, I don't care if I'm "living in the past". I'm not here to win a science faire, I'm here to make working websites. I use HTML5, CSS, Javascript, SQL and PHP (Which I note is used by some of the biggest websites in the world like Facebook)... and that's all I'll ever use. I don't need to make something as complex as Gmail... or even Facebook. All I care about is if my sites work, not if they are using the latest technology.
11:35 You can also right-click the back button, then, skipping multiple entries back, will escape the grasp of the JS hijack.
The hijack is used by advertisement websites, that appear regardless of where you click on the previous website; very annoying, especially when it's not even an overlay element that triggers this.
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.
This is why I have a custom server framework that executes at server compile time, it also optimizes dead code out for the client so I only have performance penalties for what I use
I barely fathom how that works but sounds cool as a solution
_I had to literally uninstall all, but one browser to speed up an older macbook. This is the state of Javascript frameworks and their 1GB web frankenstein_
My personal sites are dead simple clean markup with simple modern CSS. You can just write JavaScript on its own now, straight in the browser; it wasn't like that a few years ago.
I have a generator for my blog and doc pages, it was not hard to write. I have a small bit of JavaScript to do interactive search in my posts/docs but it's optimized for that task.
I kinda want to put together a series/tutorial on writing static and semi-static sites with your own lightweight tools. It's a great experience and gives a lot of control. I thinx I could do a good job with things like "here's how you keep your content indexable as long as possible", "here's how you manage locales and cross language alternates", "here's how feed readers expect to find your RSS/Atom feed", etc.
I happen to be kinda 10x when it comes to stuff like this though, so it may be a bit unreasonable to expect people to follow in my footsteps lol.
I hated the SPA idea from the start. Taking over the browser's job of loading entire page is stupid. It is very hard to build sites with SEO in mind this way.
I choose to work in a hybrid manner: html with css (well blade from Laravel and Tailwind), and if I need a a part of the page to be interactive, I just build a Vue component.
Separating concerns is my main goal. Php does only backend stuff, and Javascript only frontend stuff. If some JS component breaks, I don't want to have the whole website down.
Also, use the least amount of dependencies. If you import a library just for a function, you might be better of building the function yourself in the long term.
Page speed is very important. Remember, most people don't have a high end phone or good internet connectivity.
I love the PHP documentation both as documentation and as a website. It is soooo fast, so very focused on content, well written, correct, everything I want the web to be.
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.
JS frameworks are bad, but they're not the reason sites suck. Sites suck because of ads and tracking, and tracking on the tracking, and ten ways of doing tracking on the same page, and more tracking, and extremely heavy ads, and slow loading ads, and ads that demand to be loaded before the main content, and more ads, and then a bunch of ads, and also lots of ads. And more tracking.
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
"Stuck in the past" back when things didn't suck? Sign me up.
Good to hear voices of reason. I started web development in the 90's, then spent a long time in desktop, mobile and embedded development. When I returned to web, Angular and React were the big new approaches.
First time I tried it I could not believe the amount of installation a new project needed. And the happiness of developers to pull tons of libraries into their projects. Even for the smallest of problems, such as formatting a date, a library was added. And with it a ton of unstable dependencies, increased risk of vulnerability and as you say most of all sluggishness and a ton of code to ship often for no reason at all.
I already fought these symptoms for desktop development, but on the web this is even worse, most likely because most web developers don't know the simple answers to their problems.
But there is an overall tendency by decision makers to go for fast early shipment of a product, rather than neat and speedy code. And most overlook the backpack of problems you gather by relying on libraries that:
- Change often
- Are quickly abandoned
- Give you a headache if you need something outside the feature set of these libraries, i.e. it is usually not easy to just fill a small gap or twist something to your needs
Doing things from ground up only relying on a compact base framework takes longer initially but pays of in the long run.
That is why I am a pure Svelte/SvelteKit user. And I wished some of these concepts would make it into core JavaScript so that we would not need any of these frameworks but had a common ground helping with structuring your dev work (that is mainly how I see Svelte).
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 did my webdev bootcamp in 2021 and we learned react, I took time away from programming for health reasons but am getting back into it now. I am so surprised that some of the things we learned in class are already obsolete. It was way easier to catch up and get back into things this time than learning the first time, but it's just been a lot of relearning stuff that doesn't work anymore lol
The problem for me with these frameworks is the developer experience. It's doing *too much* for me. I like to know what's happening, so when it breaks, I can fix it.
My discomfort level with frameworks increases the deeper I get. That's not a criticism of the concept, just why I personally don't enjoy working with them. I will say that Svelte feels less like that, but majority of the time, that is just not how I do things, and I haven't seen any reason to do so.
I might feel the necessity of the size, complexity, and now importantly, number of hands in the project, increased, but I'm generally a solo developer who maintains long-term relationships with my clients, and I am not building enterprise SaaSes for corporate clients with 300+ users apiece.
In building websites and relatively simple web apps for a smallish businesses. I think we can handle this with our ol' pals HTML, CSS, JS, and a dash of jQuery, for spice.
You'd be amazed what a bit of careful planning can do (while *you* might not, but the kind of dev that decided to learn React *before* JS, might 😳).
Yeah internals documentation is always severely lacking and hopping through them in a debugger is always a mess to mentally untangle.
"Just get a better computer bro"
😂😂
What do you think about SolidJs, which has 8kb of JavaScript, or Svelte which compiles to vanilla JS?
He doesn't think, this is a rant out of a bad faith argument.
I remember talking to my professors about node js back in 2012. Everyone, even the guy that wrote it thought it was a bad idea.
We basically just got pressured and gaslit into thinking it was a good thing. It was all crap. Webassembly will hopefully help in the future. I remember when ebay moved to wasm and they said it was 10x the speed.
I remember when i first used NPM and webpack. Actual garbage.
i honestly don't think ebay even needs javascript for most of its pages
At least, we have now Vite 😀
I think a good example is the New York Times demo during the demo of original iPhone looks smooth. However if I load the New York Times of today on my top of the line iPhone it feels like dial up.
When i made a custom website the only javascript i used is the one necessary and i did initially use bootstrap but im moving away from it, the theme quick toggle javascript is absolutely necessary imo
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’m building my personal website with Astro right now. And it’s really cool I can pick specific component to have the interactivity it needed.
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.
I am looking into building my own website and with all the tools out there it gets overwhelming and since I'm primarily a back end developer all the UI stuff is hard to navigate. I just want a simple website that my wife can update. I have tried word press and it is okay but I haven't messed with php in over a decade. Any advice on what tools to use?
I'd be interested in hearing your take on the Astro framework. It seems to combine the best of both worlds by allowing static site building, hydrated framework components if you want them, and even an SPA mode if you really want it now.
Svelte and SolidJS are definitely better since they are compiled and don't use a virtual DOM. I would prefer people not use JavaScript for things that are really basic, but if you are going to or have to use those two or something like it or just use vanilla JavaScript. Right now currently writing a Fediverse client in Svelte, which I think is a example of a decent use case
You should rename the video title to how react ruined web
Yeah I thought this was just me. I turn off Java in the settings and websites load in less than a second. But with it on it loads up to 30 minutes and then crashes.
i've been studying html and css for a month now, and some friends said that it would be better to finish these studies as soon as possible to learn java or javascript, are they right? i don't know exactly what to study after the html and css...
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.
I literally cannot use some websites when my battery is already low. My phone throttles itself mostly on news websites because of how hot it gets while loading. It’s crazy. And I only have an iPhone SE 2nd gen
You hit the nail on the head with this .. great job
Yes, I agree. I am old enough to remember remember when performance not ease of use was the hallmark of software.
Svelte(kit), in my experience, is pretty good. It is a compiler, which compiles to native JS, with no virtual DOM, which improves performance (on avg), as it doesn't have to calculate changes. Also, SSR with SvelteKit hydrates it on the server.
Why won’t build tools delete functions you don’t use so the JS bundle is smaller? There is already one (Webpack tree shaking) but it’s very hard to set up and it can’t optimize away framework bloat.
Reject modernity, embrace tradition
I'm starting to believe that even moderately interactive web apps can use something like htmx. Use a bit more JS for the interaction and leave the rest to fetch / dom updates for targeted html page updates. Combine that with web components built with something like Lit and it gets even more interesting. I'm not sure but I wouldn't be surprised if >90% of web apps could do this and drop React or Vue entirely.
React had this very persuasive pitch when it first came on the scene which was "Rethink Best Practices". It turns out that may have been a huge blunder..until now.
Honestly, the only major things I bothered to learn to improve my webdev experience is figuring out how to make design mockups, vector-based objects and animations for the web in Inkscape, and make portable WebComponents in vanilla JS. Just those things alone (and a healthy dose of borrowing from CSS component libraries big and small) allowed me to keep up with frameworks for the kind of barely interactive websites I get asked to make. Not to mention starting out in a visual-first workspace before writing a single line of HTML makes it easier to come up with a unique, yet still good-looking design. And I can go back to the codebase years later, no problem. Was fortunate enough to never have to deal with Node dependency hell on the projects I had management power over. My custom components are still usable after Angular got replaced by React. And I will still be able to keep reusing them unaffected long after React is gone. I ported entire docs pages over from one framework to another in less than 10 minutes because the entire things were autogenerated from Markdown and LaTeX files. Standards tend to outlive frameworks.
really explains why youtube suddenly turned into a slow buggy disaster one day, where it takes 5 seconds to reload the page. It used to be so much faster... edit: I just plugged this videos' URL into google's own performance tester, and it failed the Core Web Vitals Assessment LOL. 4 second load... just oof
I am making a library for discord bots, and I was working on message content commands (a.k.a ?ban, ?mute) and I was integrating it with the slash commands discord provides and I actually decided to benchmark the message content parser and found that it was really slow. As a result, i decided to step back and redesign the entire message parser, as I cared about the performance. Devs seemed to not care about performance now a days
If native web APIs like WebComponents didn’t suck people wouldn’t need such basic frameworks.
Everything about the web down to the very foundation, like http being a text format is inefficient and bad, nothing was designed with the complexity of modern websites in mind obviously.
I'm a new web developer, I've started learning, I'll try to incorporate this into my knowledge and super optimize my JS usage.
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?
I'm a python dev don't do much web dev but I can relate. The issue of devs living and dying with there frame works is a issue in all languages. I have seen plenty of Django devs who had very little understanding of python.
I made my portfolio in nextjs and js ended up being 0,5 mb which is like the size of 10 pictures on my site...
Not to mention that all my npm modules were 400mb combined.
As someone just beginning to start learning computer science, I think there’s something to be said for learning just what you are actually doing instead of relying on fancy tools. I started programming using python in the terminal! And I learned so much more than if I had jumped straight into something like vs code. Maybe this is because I learned from my dad, who has been in the computing field since the early 80’s and still mainly codes in Fortran using the terminal and text editors
Great video! I fully agree with your main points... the web is really a pain to use these days. Although I think you made an incorrect statement talking about Gatsby... You said it has to run javascript before showing any html. But Gatsby generates static pages so that neither the server, nor the client needs to generate the html.. it's served prerendered, which means initial render on screen is really fast. Then it uses JS in the next step to hydrate so of course "time to interactive" could still be sluggish.
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.
In my company, we use a single page app as a software for databank transfers. There we also use a framework called SAPUI5 which i hate to work with because it is bloated as nothing else.
Though we use it only for a locally stored application for users to communicate with a databank, which makes it less of a hassle i guess. But i think from what i learned, these frameworks are not a good tool to write larger multi page websites.
Mini Rant incoming:
And sometimes abstractions annoy me. I came initially from C/C++ development. And there i learned to think how a machine allocates memory and controls them. There are frameworks for me that are harder to use then just writing C code. It is still faster since it is abstracted, yes. But i think when i would write a few functions, i would save the same time with less bloat. But i have to work in my company rn with JS and not C. I still like JS in itself, but the framework obsession i see reminds me of the OOP obsession a while back. OOP also is today still in use, but not as mythologized anymore as it was back then in 2012 and before. It is a useful tool. But a useful tool doesn't mean good for every need. When you make abstractions and distance yourself from the machine, you will lose processing power in some way. That is not necessarily bad as it makes working with it easier to some level. But it just becomes bad when you overdo it. Most of the world doesn't have also internet connections that can keep up with it.
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.
what vscode theme do you use?
I like the way I can animate page transitions with nextjs :P
Part of this is also offloading some of the processing power from the server to the client.
Couldn't agree more with this, and while the web is clearly the worst example, all modern software seems to be like this.
Here's what I've learned about that "developer experience" trickle down effect. It's almost NEVER true that easier development = better user experience. Seriously almost never.
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.
12:07 isn't that a problem ? Like I am learning web development and i am told to load the javascript after the html so no problem arrives
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
I've been using the internet since the mid-90s; I'm also a non-visual user who uses a screen-reader to access all applications. Everything for me is pretty much text only, just the way the early web was. I know we're not going to return to those days and I wouldn't want to make the web boring for everybody else, but I have watched the web get clunkier, crappier, slower, more bloated -- just as technology, including screen-reader technology, gets better and better. A week doesn't go by where I don't wish for a return to a "simpler" (and more practical) time, and I kind of hate that I feel this way. So, I appreciated this video.
I'm using HTMX lately for 99% of my frontend lately. Many times easier than working with any form of JS frontend development, and produces close to zero load on the client's web browser.
HTMX is so great and easy to use
how canvas works in it?
@@szymonbaranowski8184 any HTML should work fine.
Another issue with no simple answers! Sometimes a little bit of JS is needed, e.g. when displaying math, you may need KaTeX or MathJax, otherwise you'll have to show complex equations in plain ascii, which is not ideal. Also, I'm very much in favor of light/dark toggles for easy viewing, and that's also JS. I do agree, though, that the modern web is beyond bloat. That's why when I made my site, I only used vim (and vimwiki) and pandoc (for conversion and for the HTML template). It's not as flexible as a framework like Hugo, but at least I know exactly what's going on with the code.
I'm not anti-JavaScript, I think a little can be a good thing and can definitely enhance a webpage. The problem is when you load in scripts that are hundreds of kilobytes large just to display HTML and CSS on your page.
As a sidenote. You can implement light and dark mode using CSS without JS, but there won't be a toggle and instead it will just check if the OS has dark mode enabled.
@@h..h But you won't be able to copy it and it also doesn't scale well.
@@h..h For what? For the hundreds of math equations? Are you nuts?
I agree for toggles etc, but for equations, you could also use with MathML. I don't know how good browser support is, but it's officially listed in the HTML spec for a while now, so this seems at least possible, and it would only need a one time translation from LaTeX syntax
fwiw you should expect breaking changes from a new release major if the software is versioned with SemVer. that is what the major release is for.
BTW loved your WM setup.
Is interesting listening this point, because mainly your point is "SPA = bad" (is an oversimplification), but there is a lot of resistance to going back to fully SSR and do less things on the client.
So basically ive been trying to work with react for couple months now and still get overwhelmed. I was thinking to switch back to normal way of html, css, JavaScript web development and this video made my thinking clearer and i ended up deciding basic web development is more suitable
I started using vue but in cs50 when i found out of flask i loved it.
At work, we use Django in the Backend and mostly vanilla JS in the frontend. (Django by default comes with a jQuery installation, but if you don't use that it won't be loaded.)
I remember when I made an iPhone lookalike emulator I used five lines of js, and those were just for on button press and when button not press.
I like opinionated frameworks (i.e. Angular) as it’s efficient for my big team working on a VERY complex application. Angular also comes with a bunch of features and a great CLI tool so life gets easier. Sure, we could do everything in vanillajs but we ain’t got time, deadlines need to be reached and I’ve gotta put food on the table.
10:35 That is very important. Some years ago I was limited to a few GB of high speed traffic per month. When that was over I couldn't even complete a purchase because the shop was so convoluted, required all scripts to be loaded and prevented the use of cache. Developers had better use tools to simulate slow bandwidth and CPU instead of getting excited about the latest fad framework.
14:18 You can see how "modern" editors and code completion are terrible. The coder has to fight these features instead of just writing code. When he has to go without he is lost because he never committed the code to memory. A barrage of suggestions at every keystroke; I rather have a calm editor and code with intent.
chrome will put your old pc on the knees anyway, what's the point of optimizing the site
Not sure why this video goes over so many barely connected topics. It should talk about how JS (the programming language) ruined the web, but it talks about:
1. How some nasty websites use too much JS which slows it down (absolutely not a problem with JS itself, and I'd argue this overuse is particularly popular with "classic" devs that use JQuery and WordPress)
2. How some devs use JS frameworks for non-interactive websites (still not a JS problem, and React is not the only JS framework)
3. The npm ecosystem (barely a JS problem, and some full-featured frontend frameworks like Svelte have only 16 dependencies)
4. Performance and load times of websites (true for ordinary JS frameworks, meanwhile every single hybrid/SSR JS framework (like NextJS, which is the *official recommended way to build a React app*) has an entire chapter dedicated to reducing JS bundle sizes, reducing load times, and making sure the website works without JS completely loaded)
5. Hijacking the back button (not a problem with JS)
I also noticed that none of the code in the video is using Typescript, which makes me think that the websites you develop have no more than 1000 LOC. At this point, saying that "JS frameworks are ruining the internet" doesn't mean anything, because the benefit of those frameworks come when your project is made of hundreds of files, tens of thousands of LOC, multiple sub-projects, non-standard data flows (realtime connections), or works in non-standard environments (React-ink for example).
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 - RUclipsr: '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
As someone just getting into web design, for family owned businesses and churches in particular, this problem hits different. The entire web development and design community is trending towards resource intensive code, end users with older, slower devices get left in the dust. For these small businesses, they *need* to cater to everyone. Making a cool website that 20% of the world can enjoy is useless comforter to making a simple website that 90% can enjoy.
My thoughts exactly…when i just get into webdev. Not now though. You need a framework for speed of development, ease of collaboration and scalability. In large projects that can scale and change the vector of development you even develop a framework based on a framework because it gives better results
Hmm, I actually disable JS by default on all websites (only enabling on a per-site basis). It is ocassional that website is so dependent on JS that even stupidly simple static webpages do not display their content, and for those websites, I just click the Back button...
I am SAPUI5 developer - i got a task to develop a Fiori app which would change column amount dynamically - user could select 1-x amount of column and these columns should have data aggregated by days or weeks or years. Yeah - oData cannot be extended like that so I was doing it in JS. Imagine how big could app get before I generated everything over there. A nightmare
I completely agree with you sir. Same thing with classic hosting and the cloud.
Over a decade ago I created a PWA targeting the iPhone using jQuery mobile. I guess we're talking the iPhone 4/5 era, it took about 5 seconds to load up which I just accepted thinking it was the loading time for the full screen safari to come up, and building native because of this was a distinct possibility.
One day without even thinking I just ran an index.html file full screen with not much on it and it came up before the screen finished that slow iOS transition. It was a true eureka moment.
Since then every mobile first PWA I've built has been html and vanilla js, with zero plugins.
I really hope that webassembly leads to other languages being used for the web other than js.
@@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.
Lume is also a nice SSG i would like to see a video with your thoughts on it.
Watching this as RUclips videos keep freezing even with a huge buffer downloaded for the last 2 or 3 weeks
My web design looks like high school projects, but hey, at least it's relatively fast and nostalgic. This certainly validates my spartan html, css and very sparing dash of JS mentality.
Sparta limited everything not for sake of minimalism but to maximize core points to legendary level
and they also cheated a lot😂
@@szymonbaranowski8184 wat
I heard people using frameworks for Landing pages. Like, my friend, a single page using a picture and some texts to show your app.
Q: my current site is built off WordPress (because I'm a know-nothing n00b who never learned anything past HTML2). My website is literally just a few posts (because I'm too lazy to post more often), a portfolio of my best art (which ain't that great), and that's about it: just text and images. Would I be able to build something faster with Hugo?
Yep, I think Hugo would be a good choice for you. It's more complex than just using simple HTML, but it's not that difficult to wrap your mind around. I have a few old videos about it you can search up.
@@EricMurphyxyz Thanks! :D I'll give 'em a glance!
I experience this with Deviantart's eclipse, since when subpar eclipse got forced to everyone that use deviantart since may 20th of 2020
You should make an video on best emails alternatives to Gmail etc
I don't know what projects most of you are working on, but me as a Javascript Engeneer am working mostly on pretty complex web applications. Obviously you are right that static websites does not need frameworks at all, but what clients these days wants are nothing like a statick websites. They mostly want highly interactive data-driven applications with user tracking and state managment. Personal website, blogs etc... are not excistant anymore, becuse company representation moved to social networks, so any small busineess these days does not have a website, but a twitter account, restourants does not have page for takeout, but the app FoodPanda for example, takes care of that. Websites are nothing like websites but are fullyblown programs that do stuff, practical stuff, not scrolling pics. Once you get a real work like a programmer you may understand why frameworks and libraries are needed, also the technology moves on these days even phones now have more ram then before and companies do not care about your broke granny not being able to open 2 tabs in chrome.
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
web with js frameworks is like windows
your refresh button slowly becomes the reset button - universal blue screen solution
At least for personal projects I have this werid obsession and chanllenge to build the side without using NPM or node, instead I use js modules and other "native" alternatives.
In my experience, modern "UX design" is a huge part of the problem.
Then how can we use website that stills require JavaScript
You just convinced me to go the Ruby on Rails route without saying it once
I once heard a very good say about these frameworks including Node regarding things like their use on way to simple webpages like a blog wich dont really needs that kind of complex functionality :"You want a banana but then you will also get the gorilla holding the banana plus the entire jungle".
well i implemented my own little js router +component manager so that it'll be fast and have a godod devx at the same time, only problem is that im my case back btn has been highjacked by my router so you can't exit the site without clicking it multiple times 😅