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
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.
"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
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.
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 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.
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 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.
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
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.
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.
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... .
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.
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.
_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_
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 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.
If I weren't "forced" to use React since that's what the project I'm employed to work on is using; I would definitely prefer plain JS and actual page loads for most of the stuff I'm working on. But annoyingly and somewhat ironically; while the massive bloat of the ReactDOM is unavoidable with react; and a few 3rd party JS dependencies that somehow always includes everything no matter how I try to code split; a much bigger issue on the website I work on is actually overly high res pictures and absurdly long content; plus and all that nonsense that is injected by the analytics team with massive scripts from at least 3 different analytics providers (that of course does not have proper cache headers that Google lighthouse complain about despite 2 of those libraries with incorrect cache headers are from Google!!!) and the A/B testing scripts that also are super heavy, causes layout shifts and REGULARLY breaks things because it's a script written by analytics experts that have no React experience directly manipulating the real DOM which messes up React components a lot.
I 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.
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 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.
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 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.
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.
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 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.
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'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.
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
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.
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.
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
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.
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 have worked for a year as a web developer, making proprietary commercial web apps such as business management softwares We wrote those apps in PHP, and "vanilla" CSS and HTML. The only things we used additionally were Bootstrap and jQuery, but the latter was used less frequently. Those software have worked without issues for years and the only time they slowed down was when we wrote an inefficient query function into the backend and the client had tens of thousands of entries in a database table. Otherwise every app was insanely fast compared to modern webapps made in such things as React. Once we had one of our software checked for a project and the IT guy asked us why we used PHP as the backend of the software, why didn't we use one of these new "shiny" frameworks. I told him our PHP-based framework was way faster and lighter on resources than any of these frameworks. He had no other questions afterwards.
TLDR: Devs add a shitton of ads and trackers, use the wrong tools and write overall bad inperformant code - UA-camr: 'React and JavaScript makes website slow'
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
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.
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
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.
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.
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
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
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
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.
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.
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'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.
I once heard a very good say about these frameworks including Node regarding things like their use on way to simple webpages like a blog wich dont really needs that kind of complex functionality :"You want a banana but then you will also get the gorilla holding the banana plus the entire jungle".
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.
When i made a custom website the only javascript i used is the one necessary and i did initially use bootstrap but im moving away from it, the theme quick toggle javascript is absolutely necessary imo
dark, light, black theme switcher is like 50 lines of JS code, site independent, just copy it attach to your button and that's it, I never used frameworks, am I crazy or what?
@@JamesSmith-ix5jd depends on the person and especially browser support, if you want IE etc, im no web dev but i know many web dev should stay far away from code
I 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.
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
Web Design 101: Not every website needs to be a web app. As a developer, I can also confirm that Herd Mentality is a thing. On the whole, Devs are the biggest sheeple going. They will quite literally laugh and point at anyone not using
Tbh, it's not React, or Vue, Or Svelte, or fucking Mithril or whatever that ruined the internet. It's the sub par devs not using the toolkit properly. We use React at work to make very complex apps for a very narrow userbase; but they're blazing fast just because our devs are pretty damn good. It could be marginally faster in another framework, or even in vanilla, but realistically, the time to market would probably increase by >60%, and that's not something the company can accept, sadly.
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.
This is a very informative video, Eric! I find it extremely frustrating for some websites taking a long time to load. 10s of megs of JavaScript is quite a lot and that adds latency. Some take more than 5 seconds to load. Your website, Eric, loads in much less time, which is impressive because you don't use frameworks and stick to HTML and CSS, which is what everyone should do. JavaScript can be used to provide some interaction for some elements, like buttons or form fields. I never used a JavaScript framework myself and when I want to see how my webpage looks like, it loads instantly. Now I know why my browser's RAM usage uses 1-2 gigs of memory after opening 10-15 tabs. Because of all that JavaScript needed to load and it kills performance and increases lag time. Too much strain on system performance, but what can we do. I don't like how web developers over-use JavaScript frameworks so much to the point where their websites cannot be loaded.
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 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
My thoughts exactly…when i just get into webdev. Not now though. You need a framework for speed of development, ease of collaboration and scalability. In large projects that can scale and change the vector of development you even develop a framework based on a framework because it gives better results
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
Another issue with no simple answers! Sometimes a little bit of JS is needed, e.g. when displaying math, you may need KaTeX or MathJax, otherwise you'll have to show complex equations in plain ascii, which is not ideal. Also, I'm very much in favor of light/dark toggles for easy viewing, and that's also JS. I do agree, though, that the modern web is beyond bloat. That's why when I made my site, I only used vim (and vimwiki) and pandoc (for conversion and for the HTML template). It's not as flexible as a framework like Hugo, but at least I know exactly what's going on with the code.
I'm not anti-JavaScript, I think a little can be a good thing and can definitely enhance a webpage. The problem is when you load in scripts that are hundreds of kilobytes large just to display HTML and CSS on your page.
As a sidenote. You can implement light and dark mode using CSS without JS, but there won't be a toggle and instead it will just check if the OS has dark mode enabled.
I agree for toggles etc, but for equations, you could also use with MathML. I don't know how good browser support is, but it's officially listed in the HTML spec for a while now, so this seems at least possible, and it would only need a one time translation from LaTeX syntax
Search engines should penalise sites by how much Javascript they use. Every byte they add pushes them lower in the results, off-site scripts count ten-fold, and that penalty is multiplied by the number of sources. 100kB from your own site would be a heavy penalty, 100kB from one off-site source would be ten times as bad, and 100kB from 5 off-site sources would be 50 times as bad. Bring that in and the results would be dominated by fast-loading, script-free sites overnight.
Modern frameworks like Nuxt (vue) or Next (react) actually make building web apps easier, faster and simpler in many ways. This is especially true for large scale frontends that needs good UI/UX.
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 was one of the few new devs who managed to learn building using HTML, CSS, and JS. Turns out, that does not look attractive for companies providing internships. Ended up having to learn React JS. Though it is better in some aspects (mostly reactivity, hence it's name), it does not mean the classic HTML/CSS/JS stack is outdated. Anyways, I am happy that I could learn developing websites using both approaches.
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'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.
I absolutely hate the "hello world" is too big argument. If you wanted a web page that said hello world, you could literally write it in the span of a UA-cam comment. Hello World Hello World Clearly, I didn't need a framework to create a hello world web page. But I don't download a react boilerplate because I want to do hello world. I do it because I want to create an interactive web application, and it comes with a base filesystem and packages for me to employ.
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.
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.
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 don't know what projects most of you are working on, but me as a Javascript Engeneer am working mostly on pretty complex web applications. Obviously you are right that static websites does not need frameworks at all, but what clients these days wants are nothing like a statick websites. They mostly want highly interactive data-driven applications with user tracking and state managment. Personal website, blogs etc... are not excistant anymore, becuse company representation moved to social networks, so any small busineess these days does not have a website, but a twitter account, restourants does not have page for takeout, but the app FoodPanda for example, takes care of that. Websites are nothing like websites but are fullyblown programs that do stuff, practical stuff, not scrolling pics. Once you get a real work like a programmer you may understand why frameworks and libraries are needed, also the technology moves on these days even phones now have more ram then before and companies do not care about your broke granny not being able to open 2 tabs in chrome.
You pretty much added more value that the video. Bashing on frameworks that was used without real reason since plain HTML and CSS would be fine, is dumb. Same as using a million trackers and ads and then bashing JS for it is equally dumb
Yes! I agree, I think many people(even those with a job) don't even know how to start and end a project, even worse, a big project. Modern apps are complex, a lot of moving parts, React is a running engine for making all these parts move and it's easier to code this way, if you can't with this, keep learning. I started self taught like 4 years ago, went from just coding in python and some c++ to React, Next, trpc, setup my own T3-like template, Express, Orm's, Nextui, I managed to setup paypal and trpc, real time notifications and I maneuver all these tools with no problems, it fact they make my life easier. Just the loading states React query gives you makes everything super fun, you can show cool stuff in the screen while the data loads...
I think this video is really wrong. 1. “Websites load so many trackers” -/> “the problem is JS(js frameworks)” this issue is all the non critical requests that happen not JS 2. “You don’t want to have the page refresh every time you take an action” this can be achieved without a framework, this is a principal of SPAs but SPAs and frameworks are not mutually inclusive at all. 3. “None of these websites really need to use react” why is that? How is Facebook more technically demanding than Reddit? Like they are fairly similar products in the same near stage of scale. Fundamentally all these companies you refer too existed before react, and are fairly technically mature, they didn’t switch because of peer pressure. Also you fundamentally are mischaracterizing what a framework is. 4. Peer pressure has nothing to do with why these companies are choosing to use frameworks. 5. The end products of a framework is the same as vanilla. A framework cannot diverge from html/css/JavaScript frameworks have very little to do with what you are talking about which more has to do with practices and goals rather than the framework itself. 6. Gatsby is not comparable to react or other frontend frameworks. And doesn’t really fit your core thesis here. Also you somewhat answered your question when you said the navigation was snappier but the initial page load was slow. Initial page load is not the only metric, of course it’s important but like you named a benefit while somehow wondering what the benefit is. And just to reiterate, NONE OF THIS HAS TO DO WITH FRAMEWORKS BUT RATHER SPAs. 7. You basically strawman the hell out of the benefit of these frameworks. Also again framework =/= SPA
I remember when I got my grandma a Chromebook with 2GB of RAM back in, like, 2016. I thought there was no way she’d need anything better than that with just web browsing. Fast forward to now, where a single Facebook tab can choke that Chromebook’s resources.
What a world.
Then you see all the chuckleheads that say you should just buy a newer computer. What a wasteful mentality.
we should let people choose whether they want the fastest version of the site possible or the regular one
@@BusinessWolf1 Gmail used to have a basic HTML version that dumped all the fancy interactions for the sake of low spec PCs. Sadly, I doubt most modern sites are designed to be able to dump the heaps of JavaScript wiring them together.
@@AROAH The problem is that it's expensive to host Server Side Rendered (SSR) Website and that's why a lot of companies are moving away from it, now they just host the static files & the api.
But frameworks like SvelteKit are built for the middle ground where it prerender a static page, SSR the first request & handles the reactivity using JavaScript without virtual dom like React.
2gb in 2016 was still pretty bad
There's something worse: Electron Apps.
the worst of both worlds
Imagine a web browser written in Electron loading modern websites with heavy JS frameworks like react.
@@TheExileFox Just like hell
Yes, but some - like VS Code - can be quite polished. Slack, bashed by everyone as a memory hog, is ok too.
@@n1vz3r VS Code was written entirely with vanilla JS, so it is extremely well optimized, for an Electron app
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.
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.
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.
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
Reject modernity, embrace tradition
"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
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.
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 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.
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 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!
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
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)
My internet isnt the best. Modern internet had even the simplest of pages take far too bloody long to 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
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.
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.
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... .
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.
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.
_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_
The part about breaking things is so true. I build a newspaper website 2 years ago. Tried to perform maintenance on of these days, and it would not even run due to hundreds of dependencies that had breaking changes. I really mean hundreds.
If you use nvm and keep your packages locked to specific versions, can always go back !
@@mattmmilli8287 A solution for a problem that did not need to be there in the first place.
@@MadsonOnTheWebcare to elaborate? I don't see anything wrong with that.
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
"Stuck in the past" back when things didn't suck? Sign me up.
If I weren't "forced" to use React since that's what the project I'm employed to work on is using; I would definitely prefer plain JS and actual page loads for most of the stuff I'm working on.
But annoyingly and somewhat ironically; while the massive bloat of the ReactDOM is unavoidable with react; and a few 3rd party JS dependencies that somehow always includes everything no matter how I try to code split; a much bigger issue on the website I work on is actually overly high res pictures and absurdly long content; plus and all that nonsense that is injected by the analytics team with massive scripts from at least 3 different analytics providers (that of course does not have proper cache headers that Google lighthouse complain about despite 2 of those libraries with incorrect cache headers are from Google!!!) and the A/B testing scripts that also are super heavy, causes layout shifts and REGULARLY breaks things because it's a script written by analytics experts that have no React experience directly manipulating the real DOM which messes up React components a lot.
I 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.
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
"Just get a better computer bro"
😂😂
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 😀
This is why I have a custom server framework that executes at server compile time, it also optimizes dead code out for the client so I only have performance penalties for what I use
I barely fathom how that works but sounds cool as a solution
I 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.
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.
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 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.
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 - UA-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'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.
You should rename the video title to how react ruined web
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'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?
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.
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
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.
In my experience, modern "UX design" is a huge part of the problem.
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 have worked for a year as a web developer, making proprietary commercial web apps such as business management softwares
We wrote those apps in PHP, and "vanilla" CSS and HTML. The only things we used additionally were Bootstrap and jQuery, but the latter was used less frequently.
Those software have worked without issues for years and the only time they slowed down was when we wrote an inefficient query function into the backend and the client had tens of thousands of entries in a database table.
Otherwise every app was insanely fast compared to modern webapps made in such things as React.
Once we had one of our software checked for a project and the IT guy asked us why we used PHP as the backend of the software, why didn't we use one of these new "shiny" frameworks.
I told him our PHP-based framework was way faster and lighter on resources than any of these frameworks.
He had no other questions afterwards.
TLDR: Devs add a shitton of ads and trackers, use the wrong tools and write overall bad inperformant code - UA-camr: 'React and JavaScript makes website slow'
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
My web design looks like high school projects, but hey, at least it's relatively fast and nostalgic. This certainly validates my spartan html, css and very sparing dash of JS mentality.
Sparta limited everything not for sake of minimalism but to maximize core points to legendary level
and they also cheated a lot😂
@@szymonbaranowski8184 wat
I 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.
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.
i have a very thick skin but saying 'there is nothing inherently wrong with javascript' is like a slap in a face. dude, seriously
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.
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.
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
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
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
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.
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 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've been studying html and css for a month now, and some friends said that it would be better to finish these studies as soon as possible to learn java or javascript, are they right? i don't know exactly what to study after the html and css...
Java is for the backend, JavaScript for the frontend (mainly). So it depends on what you want to do. Personally, I'd strongly recommend learning accessibility, SEO and WAI-ARIA guidelines if you're looking to focus on the frontend!
continue learning your way to javascript, that three is the standard things in web dev. html css javascript.
You can't really do webdev without js, I'd focus on that first, then java
There is no finish, just a shift in focus. All of this stuff is constantly changing.
I'd probably do some back end stuff at the same time, even if it's just barely enough for your front end to send requests to. Or set up Postman to respond.
Options to pick from:
Front-end
htmx
JS
Solid or Svelte or Vue
React (yuck)
Back-end
Node (bonus, it's also JS)
C# (yuck)
Php (people hate on it, but I like it)
Or take a detour. Take a couple days to do some client side form validation for both US and Canadian postal codes, or phone numbers, using the pattern attribute. Regex are amazing.
I once heard a very good say about these frameworks including Node regarding things like their use on way to simple webpages like a blog wich dont really needs that kind of complex functionality :"You want a banana but then you will also get the gorilla holding the banana plus the entire jungle".
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.
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
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’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.
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
Web Design 101:
Not every website needs to be a web app.
As a developer, I can also confirm that Herd Mentality is a thing. On the whole, Devs are the biggest sheeple going. They will quite literally laugh and point at anyone not using
Tbh, it's not React, or Vue, Or Svelte, or fucking Mithril or whatever that ruined the internet. It's the sub par devs not using the toolkit properly. We use React at work to make very complex apps for a very narrow userbase; but they're blazing fast just because our devs are pretty damn good. It could be marginally faster in another framework, or even in vanilla, but realistically, the time to market would probably increase by >60%, and that's not something the company can accept, sadly.
I blame google, facebook and all those big companies for this
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.
This is a very informative video, Eric! I find it extremely frustrating for some websites taking a long time to load. 10s of megs of JavaScript is quite a lot and that adds latency. Some take more than 5 seconds to load. Your website, Eric, loads in much less time, which is impressive because you don't use frameworks and stick to HTML and CSS, which is what everyone should do. JavaScript can be used to provide some interaction for some elements, like buttons or form fields. I never used a JavaScript framework myself and when I want to see how my webpage looks like, it loads instantly.
Now I know why my browser's RAM usage uses 1-2 gigs of memory after opening 10-15 tabs. Because of all that JavaScript needed to load and it kills performance and increases lag time. Too much strain on system performance, but what can we do.
I don't like how web developers over-use JavaScript frameworks so much to the point where their websites cannot be loaded.
If you can't build a webpage in under 50KB including ALL your scripts, you're incompetent. That JS bloatware needs to die.
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 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
My thoughts exactly…when i just get into webdev. Not now though. You need a framework for speed of development, ease of collaboration and scalability. In large projects that can scale and change the vector of development you even develop a framework based on a framework because it gives better results
Reddit is good example that should use React, the problem is the another bazillion non-UI framework they used
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.
Another issue with no simple answers! Sometimes a little bit of JS is needed, e.g. when displaying math, you may need KaTeX or MathJax, otherwise you'll have to show complex equations in plain ascii, which is not ideal. Also, I'm very much in favor of light/dark toggles for easy viewing, and that's also JS. I do agree, though, that the modern web is beyond bloat. That's why when I made my site, I only used vim (and vimwiki) and pandoc (for conversion and for the HTML template). It's not as flexible as a framework like Hugo, but at least I know exactly what's going on with the code.
I'm not anti-JavaScript, I think a little can be a good thing and can definitely enhance a webpage. The problem is when you load in scripts that are hundreds of kilobytes large just to display HTML and CSS on your page.
As a sidenote. You can implement light and dark mode using CSS without JS, but there won't be a toggle and instead it will just check if the OS has dark mode enabled.
@@h..h But you won't be able to copy it and it also doesn't scale well.
@@h..h For what? For the hundreds of math equations? Are you nuts?
I agree for toggles etc, but for equations, you could also use with MathML. I don't know how good browser support is, but it's officially listed in the HTML spec for a while now, so this seems at least possible, and it would only need a one time translation from LaTeX syntax
Watching this as UA-cam videos keep freezing even with a huge buffer downloaded for the last 2 or 3 weeks
Search engines should penalise sites by how much Javascript they use. Every byte they add pushes them lower in the results, off-site scripts count ten-fold, and that penalty is multiplied by the number of sources. 100kB from your own site would be a heavy penalty, 100kB from one off-site source would be ten times as bad, and 100kB from 5 off-site sources would be 50 times as bad. Bring that in and the results would be dominated by fast-loading, script-free sites overnight.
Modern frameworks like Nuxt (vue) or Next (react) actually make building web apps easier, faster and simpler in many ways. This is especially true for large scale frontends that needs good UI/UX.
Innovation for innovation's own sake is the most problematic thing. Ive noticed so much good stuff is unecessarily buggy.
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 was one of the few new devs who managed to learn building using HTML, CSS, and JS. Turns out, that does not look attractive for companies providing internships. Ended up having to learn React JS. Though it is better in some aspects (mostly reactivity, hence it's name), it does not mean the classic HTML/CSS/JS stack is outdated.
Anyways, I am happy that I could learn developing websites using both approaches.
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'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.
Bring all the smartest web developers in a room and watch them re-invent svelte from scratch.
Svelte is actually kinda based
I absolutely hate the "hello world" is too big argument. If you wanted a web page that said hello world, you could literally write it in the span of a UA-cam comment.
Hello World
Hello World
Clearly, I didn't need a framework to create a hello world web page. But I don't download a react boilerplate because I want to do hello world. I do it because I want to create an interactive web application, and it comes with a base filesystem and packages for me to employ.
your seamless portfolio written in plain JS, html and css, that helps you land a job as React developer😊.
Part of this is also offloading some of the processing power from the server to the client.
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.
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.
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 don't know what projects most of you are working on, but me as a Javascript Engeneer am working mostly on pretty complex web applications. Obviously you are right that static websites does not need frameworks at all, but what clients these days wants are nothing like a statick websites. They mostly want highly interactive data-driven applications with user tracking and state managment. Personal website, blogs etc... are not excistant anymore, becuse company representation moved to social networks, so any small busineess these days does not have a website, but a twitter account, restourants does not have page for takeout, but the app FoodPanda for example, takes care of that. Websites are nothing like websites but are fullyblown programs that do stuff, practical stuff, not scrolling pics. Once you get a real work like a programmer you may understand why frameworks and libraries are needed, also the technology moves on these days even phones now have more ram then before and companies do not care about your broke granny not being able to open 2 tabs in chrome.
You pretty much added more value that the video. Bashing on frameworks that was used without real reason since plain HTML and CSS would be fine, is dumb.
Same as using a million trackers and ads and then bashing JS for it is equally dumb
Yes! I agree, I think many people(even those with a job) don't even know how to start and end a project, even worse, a big project. Modern apps are complex, a lot of moving parts, React is a running engine for making all these parts move and it's easier to code this way, if you can't with this, keep learning. I started self taught like 4 years ago, went from just coding in python and some c++ to React, Next, trpc, setup my own T3-like template, Express, Orm's, Nextui, I managed to setup paypal and trpc, real time notifications and I maneuver all these tools with no problems, it fact they make my life easier. Just the loading states React query gives you makes everything super fun, you can show cool stuff in the screen while the data loads...
I think this video is really wrong.
1. “Websites load so many trackers” -/> “the problem is JS(js frameworks)” this issue is all the non critical requests that happen not JS
2. “You don’t want to have the page refresh every time you take an action” this can be achieved without a framework, this is a principal of SPAs but SPAs and frameworks are not mutually inclusive at all.
3. “None of these websites really need to use react” why is that? How is Facebook more technically demanding than Reddit? Like they are fairly similar products in the same near stage of scale. Fundamentally all these companies you refer too existed before react, and are fairly technically mature, they didn’t switch because of peer pressure. Also you fundamentally are mischaracterizing what a framework is.
4. Peer pressure has nothing to do with why these companies are choosing to use frameworks.
5. The end products of a framework is the same as vanilla. A framework cannot diverge from html/css/JavaScript frameworks have very little to do with what you are talking about which more has to do with practices and goals rather than the framework itself.
6. Gatsby is not comparable to react or other frontend frameworks. And doesn’t really fit your core thesis here. Also you somewhat answered your question when you said the navigation was snappier but the initial page load was slow. Initial page load is not the only metric, of course it’s important but like you named a benefit while somehow wondering what the benefit is. And just to reiterate, NONE OF THIS HAS TO DO WITH FRAMEWORKS BUT RATHER SPAs.
7. You basically strawman the hell out of the benefit of these frameworks. Also again framework =/= SPA
I exclusively write frontend code in Go.