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.
@@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.
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.
@@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.
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.
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
"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.
ctrl shift F to look up the link in the whole of the source code in vscode but the data in question could be in the database instead of the source code? depends on how its set up
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.
@@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
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 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.
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.
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" ...
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 :
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
@@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.
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.
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
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.
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.
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.
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.
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.
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.
I love how seemingly ALL of dev is driven - like cattle - by influencer-types and FOMO. "you don't have this week's tool? You need to refactor completely or everyone will shun you" ... and yet, the voyager probe is still performing as per its mission spec. edit: framework interaction problematic because they're all shifting? We had this solved in 2002.
People are mad with these new technologies because they don't understand them(they think they know but a few can actually code with them). He literally said React gives you bad UX because some people don't know how to code a back button... .
_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_
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.
When i got in college for cs, i really liked almost everything but then i found out most people with cs jobs are web devs and I tipped my toe in web development and a week later i dropped out from college. I've never hated anything in my life as much as web developement.
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 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.
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.
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
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.
After checking out some older 90s/early 2000s websites in Web Archive, I noticed how incredibly snappy and simple those websites are, despite Web Archive's servers not having much bandwidth available. Then I started asking myself why websites today are so bloated and perform so bad even on high-end desktop PCs. Then finally found this video. It's a great overview, thanks for that. I can see why it's used(though can't really think of any *good* reasons), but things could be done so much better.
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.
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.
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'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.
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.
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.
I hate how scripting magic almost entirely eliminated actual website graphics. No matter what page you visit they all look the same. Minimalism my ass, y'all just being cheap and lazy, you bums! A pure html/css static page can scale well, look modern, be covered in graphics and still be smaller and much faster than a "modern" page only consisting of text and a small logo. Scripting a visual effect may appear more efficient than shuffling bitmap images around, but it's not if you need to pull megabytes of code to make it work. Html/css is pretty powerful if you have a little patience, and once it works, it's gonna work for years to come. Need more functionality? Sure! Script that and leave the rest alone.
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 😳).
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.
@@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.
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 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
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.
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.
@@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.
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.
TLDR: Devs add a shitton of ads and trackers, use the wrong tools and write overall bad inperformant code - TH-camr: 'React and JavaScript makes website slow'
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.
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
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 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.
This video is basically: I use hammers, a lot of people use drills, drills are good for some stuff but are bad at hammering nails. Therefore, electricity ruined craftsmanship
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!
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.
What's crazy about something like Gatsby is that you could literally do the same thing with maybe 10 lines of Javascript. All you'd need to do is write out the HTML in the index.html, mark everything besides the select page as hidden, and then toggle between them using event listeners. Handling history and URLs is as easy as push and pop as well. There's literally nothing else to it
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
reddit's new interface is literally unusable for me. I just don't get it. The old interface displayed 12+ posts at once. The new one shows 2 if you're lucky. Why would they reduce it? Maybe to squeeze more ads in?
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
Microsoft had the right idea back in 2009. "The beautiful web." Meaning, pages are fast, not in synthetic benchmarks, but in meaningful user-facing ways, fast to load, fast to render, fast to respond, smooth scrolling, smooth animations etc. This definition of beauty demands a certain level of minimalism on the part of the website, and a shift in focus on browser performance from javascript benchmarks to render performance.
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.
Web developers don't use web frameworks because they are new and trendy. They use them because they actually solve many problems. You said 3:17 These new frameworks aren't even better than the old way. You are wrong. They are better! Web developers are not idiots to do new things just because they are fancy. Most websites are janky because the Ads those websites are running. I partially agree with your point at 4:25 that static sites don't need React (or other frameworks). Yeah! Unless you are not posting frequently on your blog site. If you are, then you only have two options: 1. Generate your blog pages with a templating system. ( Server Side Rendering or pre-rendering) (or) 2. Fetch your latest post from some backend and render them dynamically (in the frontend) Do you want to receive comments from your readers? 😂 That's a whole another game! For example look at 'MDN Web Docs'. Their new site is made with react! Many websites run slowly because of poor ENGINEERING. There are many examples for extremely complicated sites running buttery smooth, but instead you are exaggerating the negative parts of the modern web. I think you might like Svelte or LitElement. JavaScript did not ruin the Modern Web. I don't want to watch this video on a desktop app instead of a browser
i actually laugh when u used recipe and newspaper sites for the poor performance of frameworks. These sites intentional load a shit ton of ads and trackers. Thats the thing that takes a year to load. Totally agree with you that the frameworks are used for the wrong use cases. A static website doesnt need to use react. The dev decided to because he wanted to
I know this is your opinion, but I would like to share mine as well. Throughout the video, I heard that things are constantly updating and changing, whether it's phones, frameworks, or other technologies, making it hard to keep track of all these rapid changes. What is the alternative? Staying with old methods and frameworks? Of course, 4GB of RAM won't be enough for today's demands because the world is progressing, and change is inevitable - and that is a good thing. A good developer, in my eyes, will continually update their skills; otherwise, they risk becoming obsolete - and that is a good thing, because it means that people will continue to improve all of the time. The world is evolving, and we, as people, are developing and creating new and more robust things. Therefore, yes, you NEED to adapt.
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.
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.
Thanks for this - I’ve had the same opinion about the overuse of JS frameworks for a while, but have been feeling self conscious about my projects which don’t use them - even though they’re all much lighter and faster than they would be with them - because of the attitude that they’re just the way you do things and if you’re not using them you’re old fashioned or missing out.
@@JamesSmith-ix5jd huh? What are you talking about - or rather, what do you think I’m talking about? Who is “they”? Perhaps you meant to reply to someone else?
@@realitypoetI think maybe they were just joking about how the news applet is a newer feature of Windows, but few people use it and it slows down Windows, kind of like a JS framework
It's crazy how the people who came up with the internet and subsequently all the standards we live in built everything to function as multiple pages not SPAs, the simulation is failing us
I used to work as a PHP programmer before going my own way. Back at the office we also had people who were always looking into the new latest thing. I personally never understood the mentality. As far as I am concerned it just needs to work and be maintainable. Constantly jumping frameworks is the opposite of that. My personal webshop is made using raw PHP + a framework for the frontend called "twig". I've not changed a single thing for 9 years and it still works, which is all I need. I guess Im just not nerdy enough to get it. I approach things from a pragmatic point of view, even though I used to work as a dev myself. I honestly don't give a rat's ass about the technology behind it, it is just a means to an end for me.
I hate how much the modern web has come to rely so heavily on Javascript in general. Especially considering people who are concenred about their privacy and want to run Tor in the safest setting, that disables Javascript entirely and if that's the case a react website won't work at all. And unless I feel like making a ton of exceptions for that website, which I would only do if I have a reason to return there. I'll probably just get my info elsewhere.
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 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
The next version of React introduces server components, where static content no longer sends JavaScript to be parsed in the way it was before. Huge win for combining reactivity with static content. I do agree though that if it’s almost entirely static content, using a JS framework is probably overkill
the problem isn't javascript, it's not frameworks or libraries or SPAs or anything. it's just bad web developers and greedy corporations that bloat their sites with ads and trackers and other annoyances. we have been able to make excellent, modern and interactive websites and web apps for years now, e.g. with next.js (RSCs now), astro, eleventy, etc. etc. but they choose not to make good apps.
I'm a web dev for a really big e-commerce site and I can tell how to fix your problems slow initial load: use react lazy loading (works for both SPA, SSG and SSR sites). bloating: use svelte/vue/preact instead of react. stay away from frameworks like gatsby, angular they're known for bloating. css bloating: use postcss to cleanup unused css, tailwind comes with builtin postcss and is like bootstrap but better. back button: works as expected in SSR and SSG, but in SPA you've to write extra logic, so that user scrolls back to same position from where they left dev experience: I agree it sucks. my project takes 30 mins to start in local dev server, because first typescript is transpiled to js, and next js uses webpack which is slow these days because it uses Node.js internally. They're working with the Rust version but it's not compatible with the babel plugins that most next js project uses.
the most painful thing about this is that startups that adopt react in their stack as if theyre gonna become the next facebook still havent learned that react is the slowest framework out there. but features gotta be churned out i guess, and deal with the headache of techdebt later, while your company suffers.
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.
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
Let's be honest. The thing that makes sites slow is not these frameworks per say, but 3rd party analytics tools which every client forces us to put in their sites.
Any interactivity with a website beyond clicking on hyperlinks contributes to making more people terminally online. Internet should be for finding information easily to enhance real life, not be a replacement for it. Making bloated websites is willfully cutting out anyone who's stuck with an old PC, which shouldn't be a shameful thing either because it means avoiding throwing out a piece of tech thus adding to e-waste.
Reddit is doing something wrong definitely because you can make the same thing in Vue as an SPA and it'll run blazing fast. Proof is there are (or at least were) third party SPA reddit clients and they run super fast.
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 also have a huge problem with npm/dependencies in general. A lot of them could be avoided and written by themselves, but the fact that so many people rely on them and inject someone elses code that they themselves don't understand is alarming.
My condescending ass will always consider the majority of web-programmers to be chimpanzees with keyboards. Just replicating crap over and over again, without understanding a bit of it.
I like to create projects with Vanilla JS and simple CSS. But, the main reason I learned React is for the JSX. So much simpler and intuitive. Also I need to eat.
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.
as someone who learned JS as my first programming language 8 years ago, every time I have come across people preaching for Angular or JQuery or React or any number of other frameworks and libraries, I read through the web page and the "why" and the "what" and I think to myself: "What is the point of all of this? I can do this all natively anyway" Also `node_modules` can go burn in a pit
"PHP is the most used server-side programming language on the web. In fact, 79.2% of all websites rely on PHP to some degree, making it one of the most popular languages among programmers and web developers due to its widespread use." Waw that's funny ! If websites are slow it's because programmers don't want to code anymore and uses libraries.
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
It's the influx of new and young developers. They are just learning the ropes, it's completely natural. As new developer generations come in it's quite hard to expect them to know the decades worth of js optimizations out of the gate.
Okay, let me write this from the perspective of a developer in Africa who uses a 8GB 6th Gen HP. The fact of the matter is that, these libraries don't make things slower. Simply put, sites with lots of ads and resources like images are slow because of all those resources need to be downloaded. Secondly sites with a lot of animations. So those are the things causing the slowdowns not the Frameworks
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
Reject modernity, embrace tradition
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.
My internet isnt the best. Modern internet had even the simplest of pages take far too bloody long to load.
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.
"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.
Ctrl+F
ctrl shift F to look up the link in the whole of the source code in vscode
but the data in question could be in the database instead of the source code?
depends on how its set up
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.
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
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
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.
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.
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!
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.
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)
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.
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
even if you block all that, the performance is still terrible
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.
@@madson-webcare to elaborate? I don't see anything wrong with that.
I love how seemingly ALL of dev is driven - like cattle - by influencer-types and FOMO. "you don't have this week's tool? You need to refactor completely or everyone will shun you"
... and yet, the voyager probe is still performing as per its mission spec.
edit: framework interaction problematic because they're all shifting? We had this solved in 2002.
Yes, I'm tired of all the tools and build steps of modern frameworks.
People are mad with these new technologies because they don't understand them(they think they know but a few can actually code with them). He literally said React gives you bad UX because some people don't know how to code a back button... .
_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_
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.
When i got in college for cs, i really liked almost everything but then i found out most people with cs jobs are web devs and I tipped my toe in web development and a week later i dropped out from college. I've never hated anything in my life as much as web developement.
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 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.
@@TheNewton Ctrl + P > PDF
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.
"Stuck in the past" back when things didn't suck? Sign me up.
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
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
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.
After checking out some older 90s/early 2000s websites in Web Archive, I noticed how incredibly snappy and simple those websites are, despite Web Archive's servers not having much bandwidth available. Then I started asking myself why websites today are so bloated and perform so bad even on high-end desktop PCs. Then finally found this video. It's a great overview, thanks for that. I can see why it's used(though can't really think of any *good* reasons), but things could be done so much better.
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.
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.
If you can't build a webpage in under 50KB including ALL your scripts, you're incompetent. That JS bloatware needs to die.
"Just get a better computer bro"
😂😂
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'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.
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
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 - TH-camr: '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
I hate how scripting magic almost entirely eliminated actual website graphics. No matter what page you visit they all look the same. Minimalism my ass, y'all just being cheap and lazy, you bums!
A pure html/css static page can scale well, look modern, be covered in graphics and still be smaller and much faster than a "modern" page only consisting of text and a small logo. Scripting a visual effect may appear more efficient than shuffling bitmap images around, but it's not if you need to pull megabytes of code to make it work.
Html/css is pretty powerful if you have a little patience, and once it works, it's gonna work for years to come. Need more functionality? Sure! Script that and leave the rest alone.
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.
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.
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 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
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.
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.
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.
TLDR: Devs add a shitton of ads and trackers, use the wrong tools and write overall bad inperformant code - TH-camr: 'React and JavaScript makes website slow'
Text and layouts load like individual images. That's the problem!
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 wouldn't say Javascript ruined the web, I would say "People using javascript frameworks that aren't needed for the current site ruined the web"
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.
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.
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 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.
This video is basically:
I use hammers,
a lot of people use drills,
drills are good for some stuff but are bad at hammering nails.
Therefore, electricity ruined craftsmanship
In my experience, modern "UX design" is a huge part of the problem.
Don't blame JS. Bad developers abound.
Agree sir
You should rename the video title to how react ruined web
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.
What's crazy about something like Gatsby is that you could literally do the same thing with maybe 10 lines of Javascript. All you'd need to do is write out the HTML in the index.html, mark everything besides the select page as hidden, and then toggle between them using event listeners. Handling history and URLs is as easy as push and pop as well. There's literally nothing else to it
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
reddit's new interface is literally unusable for me. I just don't get it. The old interface displayed 12+ posts at once. The new one shows 2 if you're lucky. Why would they reduce it? Maybe to squeeze more ads in?
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
Microsoft had the right idea back in 2009. "The beautiful web." Meaning, pages are fast, not in synthetic benchmarks, but in meaningful user-facing ways, fast to load, fast to render, fast to respond, smooth scrolling, smooth animations etc. This definition of beauty demands a certain level of minimalism on the part of the website, and a shift in focus on browser performance from javascript benchmarks to render performance.
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
The internet need to suckless
Web developers don't use web frameworks because they are new and trendy. They use them because they actually solve many problems.
You said
3:17 These new frameworks aren't even better than the old way.
You are wrong. They are better!
Web developers are not idiots to do new things just because they are fancy.
Most websites are janky because the Ads those websites are running.
I partially agree with your point at 4:25 that static sites don't need React (or other frameworks). Yeah! Unless you are not posting frequently on your blog site.
If you are, then you only have two options:
1. Generate your blog pages with a templating system. ( Server Side Rendering or pre-rendering)
(or)
2. Fetch your latest post from some backend and render them dynamically (in the frontend)
Do you want to receive comments from your readers? 😂
That's a whole another game!
For example look at 'MDN Web Docs'. Their new site is made with react!
Many websites run slowly because of poor ENGINEERING.
There are many examples for extremely complicated sites running buttery smooth, but instead you are exaggerating the negative parts of the modern web.
I think you might like Svelte or LitElement.
JavaScript did not ruin the Modern Web.
I don't want to watch this video on a desktop app instead of a browser
i actually laugh when u used recipe and newspaper sites for the poor performance of frameworks. These sites intentional load a shit ton of ads and trackers. Thats the thing that takes a year to load.
Totally agree with you that the frameworks are used for the wrong use cases. A static website doesnt need to use react. The dev decided to because he wanted to
I know this is your opinion, but I would like to share mine as well. Throughout the video, I heard that things are constantly updating and changing, whether it's phones, frameworks, or other technologies, making it hard to keep track of all these rapid changes.
What is the alternative? Staying with old methods and frameworks? Of course, 4GB of RAM won't be enough for today's demands because the world is progressing, and change is inevitable - and that is a good thing.
A good developer, in my eyes, will continually update their skills; otherwise, they risk becoming obsolete - and that is a good thing, because it means that people will continue to improve all of the time.
The world is evolving, and we, as people, are developing and creating new and more robust things. Therefore, yes, you NEED to adapt.
BTW loved your WM setup.
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.
Part of this is also offloading some of the processing power from the server to the client.
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.
Thanks for this - I’ve had the same opinion about the overuse of JS frameworks for a while, but have been feeling self conscious about my projects which don’t use them - even though they’re all much lighter and faster than they would be with them - because of the attitude that they’re just the way you do things and if you’re not using them you’re old fashioned or missing out.
They have a very nice news applet in windows, if you don't use it you are soo old fashioned and missing out of things.
@@JamesSmith-ix5jd huh? What are you talking about - or rather, what do you think I’m talking about? Who is “they”? Perhaps you meant to reply to someone else?
@@realitypoetI think maybe they were just joking about how the news applet is a newer feature of Windows, but few people use it and it slows down Windows, kind of like a JS framework
@@ahdog8 ah, I see - I haven’t used Windows in a long time.
It's crazy how the people who came up with the internet and subsequently all the standards we live in built everything to function as multiple pages not SPAs, the simulation is failing us
I used to work as a PHP programmer before going my own way. Back at the office we also had people who were always looking into the new latest thing. I personally never understood the mentality. As far as I am concerned it just needs to work and be maintainable. Constantly jumping frameworks is the opposite of that. My personal webshop is made using raw PHP + a framework for the frontend called "twig". I've not changed a single thing for 9 years and it still works, which is all I need. I guess Im just not nerdy enough to get it. I approach things from a pragmatic point of view, even though I used to work as a dev myself. I honestly don't give a rat's ass about the technology behind it, it is just a means to an end for me.
I hate how much the modern web has come to rely so heavily on Javascript in general. Especially considering people who are concenred about their privacy and want to run Tor in the safest setting, that disables Javascript entirely and if that's the case a react website won't work at all. And unless I feel like making a ton of exceptions for that website, which I would only do if I have a reason to return there. I'll probably just get my info elsewhere.
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 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
The next version of React introduces server components, where static content no longer sends JavaScript to be parsed in the way it was before. Huge win for combining reactivity with static content. I do agree though that if it’s almost entirely static content, using a JS framework is probably overkill
the problem isn't javascript, it's not frameworks or libraries or SPAs or anything.
it's just bad web developers and greedy corporations that bloat their sites with ads and trackers and other annoyances.
we have been able to make excellent, modern and interactive websites and web apps for years now, e.g. with next.js (RSCs now), astro, eleventy, etc. etc. but they choose not to make good apps.
your seamless portfolio written in plain JS, html and css, that helps you land a job as React developer😊.
I'm a web dev for a really big e-commerce site and I can tell how to fix your problems
slow initial load: use react lazy loading (works for both SPA, SSG and SSR sites).
bloating: use svelte/vue/preact instead of react. stay away from frameworks like gatsby, angular they're known for bloating.
css bloating: use postcss to cleanup unused css, tailwind comes with builtin postcss and is like bootstrap but better.
back button: works as expected in SSR and SSG, but in SPA you've to write extra logic, so that user scrolls back to same position from where they left
dev experience: I agree it sucks. my project takes 30 mins to start in local dev server, because first typescript is transpiled to js, and next js uses webpack which is slow these days because it uses Node.js internally. They're working with the Rust version but it's not compatible with the babel plugins that most next js project uses.
the most painful thing about this is that startups that adopt react in their stack as if theyre gonna become the next facebook still havent learned that react is the slowest framework out there.
but features gotta be churned out i guess, and deal with the headache of techdebt later, while your company suffers.
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.
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
Let's be honest. The thing that makes sites slow is not these frameworks per say, but 3rd party analytics tools which every client forces us to put in their sites.
Any interactivity with a website beyond clicking on hyperlinks contributes to making more people terminally online.
Internet should be for finding information easily to enhance real life, not be a replacement for it.
Making bloated websites is willfully cutting out anyone who's stuck with an old PC, which shouldn't be a shameful thing either because it means avoiding throwing out a piece of tech thus adding to e-waste.
Reddit is doing something wrong definitely because you can make the same thing in Vue as an SPA and it'll run blazing fast. Proof is there are (or at least were) third party SPA reddit clients and they run super fast.
Reddit is here to spy on you not to help you in any way
it's slow for a reason
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 also have a huge problem with npm/dependencies in general. A lot of them could be avoided and written by themselves, but the fact that so many people rely on them and inject someone elses code that they themselves don't understand is alarming.
My condescending ass will always consider the majority of web-programmers to be chimpanzees with keyboards. Just replicating crap over and over again, without understanding a bit of it.
I like to create projects with Vanilla JS and simple CSS.
But, the main reason I learned React is for the JSX. So much simpler and intuitive. Also I need to eat.
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.
as someone who learned JS as my first programming language 8 years ago, every time I have come across people preaching for Angular or JQuery or React or any number of other frameworks and libraries, I read through the web page and the "why" and the "what" and I think to myself: "What is the point of all of this? I can do this all natively anyway"
Also `node_modules` can go burn in a pit
"PHP is the most used server-side programming language on the web. In fact, 79.2% of all websites rely on PHP to some degree, making it one of the most popular languages among programmers and web developers due to its widespread use."
Waw that's funny !
If websites are slow it's because programmers don't want to code anymore and uses libraries.
My angular 16 project produce 600kb js file from 550kb typescript ... not baad not badd :D
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
It's the influx of new and young developers. They are just learning the ropes, it's completely natural. As new developer generations come in it's quite hard to expect them to know the decades worth of js optimizations out of the gate.
Okay, let me write this from the perspective of a developer in Africa who uses a 8GB 6th Gen HP. The fact of the matter is that, these libraries don't make things slower. Simply put, sites with lots of ads and resources like images are slow because of all those resources need to be downloaded. Secondly sites with a lot of animations. So those are the things causing the slowdowns not the Frameworks