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.
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'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.
I'm originally a C++ dev but at my last job had to take over a few web projects and I didn't want to learn React so I wrote them in native JS, which at first felt wrong because the way people talk that is an outdated way of doing things, but slowly over time I realized my web apps were way faster than any of the ones people with frameworks were making. The thing is it's tempting cause a lot of them have cool functionalitt built in but it almost always bloats what you're building and people don't seem to consider this and just default to it
That's just your point of view because you didn't use JS Frameworks. Let me assure you that those framework e.g. React are more optimized than you vanillaJS code because those are actually compiled into vanillaJS, minified, optimized and bundled into small parts before they are sent to the user's web browser 😅
@@julianojosoa2145 Here's the thing. It's literally faster to refresh the whole page than to do the whole retained mode nonsense. Go to some professor's webpage which are usually pure html+css. Click on links. It's _instant._ Bringing in a bloated mess like react to avoid refreshing the whole screens is just bonzo.
@@julianojosoa2145 Here's the thing. It's literally faster to refresh the whole page than to do the whole retained mode nonsense. Go to some professor's webpage which are usually pure html+css. Click on links. It's _instant._ Bringing in a bloated mess like react just to avoid full screen refresh is bonzo.
I remember when I first tried using Node and use express to make a simple server, the moment I saw 100 packages download I knew there was something wrong.
That was me with Angular for the first time. "200 MB for Hello World?! This is ridiculous!" Of course a lot of the packages can be installed globally, so you don't need another 250 MB for every project. If you think about it, you're basically downloading a compiler for a new language, in source code form. Still, it's kind of crazy how many dependencies there are. "Don't reinvent the wheel" has turned into "Build a car by buying every part from a separate vendor." ... and then my package manager breaks because i ran "sudo npm update" ...
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.
"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
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.
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.
JS frameworks are bad, but they're not the reason sites suck. Sites suck because of ads and tracking, and tracking on the tracking, and ten ways of doing tracking on the same page, and more tracking, and extremely heavy ads, and slow loading ads, and ads that demand to be loaded before the main content, and more ads, and then a bunch of ads, and also lots of ads. And more tracking.
Sites suck because an industry web-dev is severely lacking in professional rigor that knows how to say no to clients fumbling their own business interests.
The part about breaking things is so true. I build a newspaper website 2 years ago. Tried to perform maintenance on of these days, and it would not even run due to hundreds of dependencies that had breaking changes. I really mean hundreds.
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.
People are mad with these new technologies because they don't understand them(they think they know but a few can actually code with them). He literally said React gives you bad UX because some people don't know how to code a back button... .
I 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.
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.
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.
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
The problem for me with these frameworks is the developer experience. It's doing *too much* for me. I like to know what's happening, so when it breaks, I can fix it. My discomfort level with frameworks increases the deeper I get. That's not a criticism of the concept, just why I personally don't enjoy working with them. I will say that Svelte feels less like that, but majority of the time, that is just not how I do things, and I haven't seen any reason to do so. I might feel the necessity of the size, complexity, and now importantly, number of hands in the project, increased, but I'm generally a solo developer who maintains long-term relationships with my clients, and I am not building enterprise SaaSes for corporate clients with 300+ users apiece. In building websites and relatively simple web apps for a smallish businesses. I think we can handle this with our ol' pals HTML, CSS, JS, and a dash of jQuery, for spice. You'd be amazed what a bit of careful planning can do (while *you* might not, but the kind of dev that decided to learn React *before* JS, might 😳).
I completely agree with everything you say. I also don't understand what is going on on some websites when toggling dark mode and the page seems to be doing some heavy stuff while the screen flickers. And all JS should do is add a 'dark' class and store the user's preference. The rest is done with CSS, even to determine the user's OS theme settings. I also don't understand the purpose of most animations on modern websites, is it really that pleasing to end-users? People should really care more about things like accessibility and performance.
1. An explanation why some websites have dark mode flicker is a when the user selects the "System" option when choosing a theme. The system option automatically follows the user device's color theme and can only be applied by JS when the actual website has loaded. Before the website loads, it will appear in its default theme (usually white) which causes an unavoidable flicker. And yes, this is unavoidable even in a pure SSR or static website. 2. Yes, animations are surprisingly good for increasing your product's value.
@@okie9025 CSS has a "prefers-color-scheme" media query, that should resolve immediately before the page is rendered. A script could overwrite that with its own logic, but flickering before going dark is not an inherent part of how the web is designed.
A comment on the animations on the web: It's there for those who appreciates the presentation, especially on the kinds of websites that are trying to be artsy-ish. The animations bring something unique to the idea you're standing behind, whether it's for an art project, or your portfolio. To quote a comment of my past mentor: "The Web doesn't necessarily have to be fast and optimized, as long as you are satisfied with what you believe in." As for dark mode, most of the time it's a fancy version of "Telling JS to add some class to some CSS somewhere", with additional project architect complexity. That's how I see it through all of my past projects that touched upon this matter.
_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_
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.
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.
Good to hear voices of reason. I started web development in the 90's, then spent a long time in desktop, mobile and embedded development. When I returned to web, Angular and React were the big new approaches. First time I tried it I could not believe the amount of installation a new project needed. And the happiness of developers to pull tons of libraries into their projects. Even for the smallest of problems, such as formatting a date, a library was added. And with it a ton of unstable dependencies, increased risk of vulnerability and as you say most of all sluggishness and a ton of code to ship often for no reason at all. I already fought these symptoms for desktop development, but on the web this is even worse, most likely because most web developers don't know the simple answers to their problems. But there is an overall tendency by decision makers to go for fast early shipment of a product, rather than neat and speedy code. And most overlook the backpack of problems you gather by relying on libraries that: - Change often - Are quickly abandoned - Give you a headache if you need something outside the feature set of these libraries, i.e. it is usually not easy to just fill a small gap or twist something to your needs Doing things from ground up only relying on a compact base framework takes longer initially but pays of in the long run. That is why I am a pure Svelte/SvelteKit user. And I wished some of these concepts would make it into core JavaScript so that we would not need any of these frameworks but had a common ground helping with structuring your dev work (that is mainly how I see Svelte).
they try hard to choke themselves to death building next floors to a tower with too unstable foundation not seeing the problem is the whole tower itself and making it standard they keep everyone a hostage of this as companies hate to rewrite anything and start fresh in different technology things in js world grow like cancer cells and instead of healing they decide to live with multiple sicknesses calling them not system error but features
I did my webdev bootcamp in 2021 and we learned react, I took time away from programming for health reasons but am getting back into it now. I am so surprised that some of the things we learned in class are already obsolete. It was way easier to catch up and get back into things this time than learning the first time, but it's just been a lot of relearning stuff that doesn't work anymore lol
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.
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
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.
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'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.
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.
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
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 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.
Why won’t build tools delete functions you don’t use so the JS bundle is smaller? There is already one (Webpack tree shaking) but it’s very hard to set up and it can’t optimize away framework bloat.
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.
After checking out some older 90s/early 2000s websites in Web Archive, I noticed how incredibly snappy and simple those websites are, despite Web Archive's servers not having much bandwidth available. Then I started asking myself why websites today are so bloated and perform so bad even on high-end desktop PCs. Then finally found this video. It's a great overview, thanks for that. I can see why it's used(though can't really think of any *good* reasons), but things could be done so much better.
I'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.
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.
As someone just beginning to start learning computer science, I think there’s something to be said for learning just what you are actually doing instead of relying on fancy tools. I started programming using python in the terminal! And I learned so much more than if I had jumped straight into something like vs code. Maybe this is because I learned from my dad, who has been in the computing field since the early 80’s and still mainly codes in Fortran using the terminal and text editors
I hate how scripting magic almost entirely eliminated actual website graphics. No matter what page you visit they all look the same. Minimalism my ass, y'all just being cheap and lazy, you bums! A pure html/css static page can scale well, look modern, be covered in graphics and still be smaller and much faster than a "modern" page only consisting of text and a small logo. Scripting a visual effect may appear more efficient than shuffling bitmap images around, but it's not if you need to pull megabytes of code to make it work. Html/css is pretty powerful if you have a little patience, and once it works, it's gonna work for years to come. Need more functionality? Sure! Script that and leave the rest alone.
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
Honestly, the only major things I bothered to learn to improve my webdev experience is figuring out how to make design mockups, vector-based objects and animations for the web in Inkscape, and make portable WebComponents in vanilla JS. Just those things alone (and a healthy dose of borrowing from CSS component libraries big and small) allowed me to keep up with frameworks for the kind of barely interactive websites I get asked to make. Not to mention starting out in a visual-first workspace before writing a single line of HTML makes it easier to come up with a unique, yet still good-looking design. And I can go back to the codebase years later, no problem. Was fortunate enough to never have to deal with Node dependency hell on the projects I had management power over. My custom components are still usable after Angular got replaced by React. And I will still be able to keep reusing them unaffected long after React is gone. I ported entire docs pages over from one framework to another in less than 10 minutes because the entire things were autogenerated from Markdown and LaTeX files. Standards tend to outlive frameworks.
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.
I like opinionated frameworks (i.e. Angular) as it’s efficient for my big team working on a VERY complex application. Angular also comes with a bunch of features and a great CLI tool so life gets easier. Sure, we could do everything in vanillajs but we ain’t got time, deadlines need to be reached and I’ve gotta put food on the table.
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 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
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.
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.
Yes, you should load the JavaScript after the HTML, but some JS frameworks initially ship no HTML to the browser and render it all dynamically with the JS framework, which causes issues
Svelte(kit), in my experience, is pretty good. It is a compiler, which compiles to native JS, with no virtual DOM, which improves performance (on avg), as it doesn't have to calculate changes. Also, SSR with SvelteKit hydrates it on the server.
I made my portfolio in nextjs and js ended up being 0,5 mb which is like the size of 10 pictures on my site... Not to mention that all my npm modules were 400mb combined.
reddit's new interface is literally unusable for me. I just don't get it. The old interface displayed 12+ posts at once. The new one shows 2 if you're lucky. Why would they reduce it? Maybe to squeeze more ads in?
Great video! I fully agree with your main points... the web is really a pain to use these days. Although I think you made an incorrect statement talking about Gatsby... You said it has to run javascript before showing any html. But Gatsby generates static pages so that neither the server, nor the client needs to generate the html.. it's served prerendered, which means initial render on screen is really fast. Then it uses JS in the next step to hydrate so of course "time to interactive" could still be sluggish.
That sounds like you fell for marketing talk. If there's another step before payload is displayed, then it's not a static page at all. Whether it's called "hydration" or something else is irrelevant. Another framework that is part of the problem. If you want the solution, get rid of frameworks entirely!
@@Alien426 Not sure what you are arguing against here... I said that the initial paint is very fast, but that TTI can be sluggish. And don't worry.. I havn't fallen for any marketing talk. I'm speaking from years of trial and error as a frontend developer. In fact I really dislike Gatsby because it's bloated and build times are really bad. All I'm saying is that most of html is served on the first fetch unlike Create React App for example.
...and that the first fetch will be very fast since it's serving a static site, meaning it's actual static .html + .css files on the server, not server side generated markup.
Yeah I thought this was just me. I turn off Java in the settings and websites load in less than a second. But with it on it loads up to 30 minutes and then crashes.
Is interesting listening this point, because mainly your point is "SPA = bad" (is an oversimplification), but there is a lot of resistance to going back to fully SSR and do less things on the client.
I am looking into building my own website and with all the tools out there it gets overwhelming and since I'm primarily a back end developer all the UI stuff is hard to navigate. I just want a simple website that my wife can update. I have tried word press and it is okay but I haven't messed with php in over a decade. Any advice on what tools to use?
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
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.
Just curious as a person who isn't in web development, why would you need to create a website using a framework even if it does simplify the process of building it, couldn't you just build... the whole website yourself without having to make those performance sacrifices? I know that maybe for certain features like support chats, or social features like messaging or even more complex features, I would understand using a framework. But for everything else not a whole lot.
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
Web developers don't use web frameworks because they are new and trendy. They use them because they actually solve many problems. You said 3:17 These new frameworks aren't even better than the old way. You are wrong. They are better! Web developers are not idiots to do new things just because they are fancy. Most websites are janky because the Ads those websites are running. I partially agree with your point at 4:25 that static sites don't need React (or other frameworks). Yeah! Unless you are not posting frequently on your blog site. If you are, then you only have two options: 1. Generate your blog pages with a templating system. ( Server Side Rendering or pre-rendering) (or) 2. Fetch your latest post from some backend and render them dynamically (in the frontend) Do you want to receive comments from your readers? 😂 That's a whole another game! For example look at 'MDN Web Docs'. Their new site is made with react! Many websites run slowly because of poor ENGINEERING. There are many examples for extremely complicated sites running buttery smooth, but instead you are exaggerating the negative parts of the modern web. I think you might like Svelte or LitElement. JavaScript did not ruin the Modern Web. I don't want to watch this video on a desktop app instead of a browser
i actually laugh when u used recipe and newspaper sites for the poor performance of frameworks. These sites intentional load a shit ton of ads and trackers. Thats the thing that takes a year to load. Totally agree with you that the frameworks are used for the wrong use cases. A static website doesnt need to use react. The dev decided to because he wanted to
I 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 like to create projects with Vanilla JS and simple CSS. But, the main reason I learned React is for the JSX. So much simpler and intuitive. Also I need to eat.
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'm a web dev for a really big e-commerce site and I can tell how to fix your problems slow initial load: use react lazy loading (works for both SPA, SSG and SSR sites). bloating: use svelte/vue/preact instead of react. stay away from frameworks like gatsby, angular they're known for bloating. css bloating: use postcss to cleanup unused css, tailwind comes with builtin postcss and is like bootstrap but better. back button: works as expected in SSR and SSG, but in SPA you've to write extra logic, so that user scrolls back to same position from where they left dev experience: I agree it sucks. my project takes 30 mins to start in local dev server, because first typescript is transpiled to js, and next js uses webpack which is slow these days because it uses Node.js internally. They're working with the Rust version but it's not compatible with the babel plugins that most next js project uses.
I am SAPUI5 developer - i got a task to develop a Fiori app which would change column amount dynamically - user could select 1-x amount of column and these columns should have data aggregated by days or weeks or years. Yeah - oData cannot be extended like that so I was doing it in JS. Imagine how big could app get before I generated everything over there. A nightmare
I'd be interested in hearing your take on the Astro framework. It seems to combine the best of both worlds by allowing static site building, hydrated framework components if you want them, and even an SPA mode if you really want it now.
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...
At work, we use Django in the Backend and mostly vanilla JS in the frontend. (Django by default comes with a jQuery installation, but if you don't use that it won't be loaded.)
I 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.
The problem: so you want interactivity but you don't know exactly when, where and how much ? well you could just use vanilla js but that's a bad experience, so instead just use a framework for SPAs by default. Whose fault is it ? and why is it not the browser vendors' fault for refusing to evolve into what 95% programmers are doing ? The problem with these frameworks is that js was never meant to be a language to do rendering with, it's just not fast enough. But with native (at the browser level, in C++) implementations of react you could do sooo much better probably 100x improvements
Reddit is doing something wrong definitely because you can make the same thing in Vue as an SPA and it'll run blazing fast. Proof is there are (or at least were) third party SPA reddit clients and they run super fast.
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
Design your code for your use case. Frameworks can often make development and maintenance much easier and therefore for small apps they can be preferable. It's a similar debate to monolith vs microservices, or Kubernetes vs bare metal servers. There are pros and cons; feature differentials; maintenance and development considerations; even business cases etc. that all need to be considered, and being dogmatic or famatical about any given approach is usually detrimental to the end result. You'd never make a full enterprise system with a lot of data dependencies as a pure microservices design due to performance considerations, but microservices are great for developing and maintaining simpler product stacks, for example. Build for your use case; not for what you see as ideal.
Q: my current site is built off WordPress (because I'm a know-nothing n00b who never learned anything past HTML2). My website is literally just a few posts (because I'm too lazy to post more often), a portfolio of my best art (which ain't that great), and that's about it: just text and images. Would I be able to build something faster with Hugo?
Yep, I think Hugo would be a good choice for you. It's more complex than just using simple HTML, but it's not that difficult to wrap your mind around. I have a few old videos about it you can search up.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
I remember when I got my grandma a Chromebook with 2GB of RAM back in, like, 2016. I thought there was no way she’d need anything better than that with just web browsing. Fast forward to now, where a single Facebook tab can choke that Chromebook’s resources.
What a world.
Then you see all the chuckleheads that say you should just buy a newer computer. What a wasteful mentality.
we should let people choose whether they want the fastest version of the site possible or the regular one
@@BusinessWolf1 Gmail used to have a basic HTML version that dumped all the fancy interactions for the sake of low spec PCs. Sadly, I doubt most modern sites are designed to be able to dump the heaps of JavaScript wiring them together.
@@AROAH The problem is that it's expensive to host Server Side Rendered (SSR) Website and that's why a lot of companies are moving away from it, now they just host the static files & the api.
But frameworks like SvelteKit are built for the middle ground where it prerender a static page, SSR the first request & handles the reactivity using JavaScript without virtual dom like React.
2gb in 2016 was still pretty bad
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.
Reject modernity, embrace tradition
It's a complicated problem because indeed not knowing React or Vue today is a major hinderance to your career as a developer and you'll struggle to find work that does not require production experience with these frameworks. This alone already motivates people to use frameworks for everything
At the same time yes like most things development often chases trends rather than focusing on objective data driven decision making.
The more javascript you add to something the more problems you're creating... more libraries means more time spent debugging other people's code.
Major problems: Nobody is really doing things data driven, nobody cares about underpowered devices, nobody cares about data limits, nobody cares about acessibility, mobile web development is still an afterthought. And so in many ways webdevelopment took 1 step forward and 2 steps back and lost track of what the ultimate goal is
What I find hilarious is that people act like SPAs are "more efficient" because you don't need to keep loading new pages all the time. My brother in Christ, now you need the whole goddamn website loaded in RAM right from the start, mobile data through the roof, the web was paginated for a reason and loading pages takes 0.1 second each. Stupidest aspect of the modern web.
Bring on the era of WebAssembly I guess
@@colbyboucher6391 If I may play devil's advocate, the idea is that the program is usually smaller than the data. You're not loading the entire contents of the server's hard drive, you're loading components that specify how to display and interact with data. That data is usually loaded on demand through xhr requests or the fetch api. It just so happens that most frameworks are so dependency heavy, the assumption that program size < data size might not hold up well on the modern web. With React, you as an end user have to load the entire React framework from one of Meta's CDN servers. With something like Svelte, on the other hand, it's all compiled down so the end user only has to load a relatively small script with not much more than the page developer's actual logic, even though the developer needs hundreds of MB of dependencies to generate that smaller file. The overhead of the framework itself to the end user is in the single digit kB range.
But it's really all the ads and trackers that slow things down more than anything else.
Web assembly is great in many ways, but it can't touch the DOM. It still has to go through javascript to actually do anything, or whatever hosting environment is embedding it. I love it as an open standard for a VM to use in lieu of things like Java or .NET, but on an actual web page its only advantage is computing power for raw number crunching, or bringing old legacy native programs onto the web, not so much in the reactive UI department. Blazor, for example, needs a couple MB of code just to bootstrap .NET in a WASM environment. Rust and C with emscripten fare a little better at 100-200 kB, and a raw Rust or C wasm module with no support layer takes barely anything beyond the actual functions you write. So while the performance is not an advantage in the UI case, it does allow development in other languages besides Javascript, which is a plus all by itself.
"Major problems: Nobody is really doing things data driven, nobody cares about underpowered devices, nobody cares about data limits, "
Which is why I believe regulation of soft-dev or web-dev will happen in our lifetime.
At least in the case of accessibility there are very defined legal consequences that can force businesses to care.
@@TheNewton I couldn't advocate for legally regulating web development in this sense because the definition of "old device" is constantly in flux, and lawmakers are notoriously bad when it comes to ever evolving tech.
Additionally, there's an argument that this would stifle innovation from companies trying to do new things as there's now a business overhead associated with this kind of regulation. If you want to legally force old device support then you can say goodbye to using emerging / semi-mainstream technologies such as WebAssembly (ruling out anything made using Microsoft's Blazor, for example).
If there is such a regulation ever proposed, this is why I believe that the political tech lobbyists would never stand for it.
I’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.
My internet isnt the best. Modern internet had even the simplest of pages take far too bloody long to load.
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!
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.
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
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.
"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
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
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)
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.
JS frameworks are bad, but they're not the reason sites suck. Sites suck because of ads and tracking, and tracking on the tracking, and ten ways of doing tracking on the same page, and more tracking, and extremely heavy ads, and slow loading ads, and ads that demand to be loaded before the main content, and more ads, and then a bunch of ads, and also lots of ads. And more tracking.
I think you forgot to add tracking
getting things for free means getting much more crap with it as punishment for not paying
Sites suck because an industry web-dev is severely lacking in professional rigor that knows how to say no to clients fumbling their own business interests.
@@TheNewtonagreed
even if you block all that, the performance is still terrible
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.
The part about breaking things is so true. I build a newspaper website 2 years ago. Tried to perform maintenance on of these days, and it would not even run due to hundreds of dependencies that had breaking changes. I really mean hundreds.
If you use nvm and keep your packages locked to specific versions, can always go back !
@@mattmmilli8287 A solution for a problem that did not need to be there in the first place.
@@madson-webcare to elaborate? I don't see anything wrong with that.
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.
Yes, I'm tired of all the tools and build steps of modern frameworks.
People are mad with these new technologies because they don't understand them(they think they know but a few can actually code with them). He literally said React gives you bad UX because some people don't know how to code a back button... .
I 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.
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.
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
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
The problem for me with these frameworks is the developer experience. It's doing *too much* for me. I like to know what's happening, so when it breaks, I can fix it.
My discomfort level with frameworks increases the deeper I get. That's not a criticism of the concept, just why I personally don't enjoy working with them. I will say that Svelte feels less like that, but majority of the time, that is just not how I do things, and I haven't seen any reason to do so.
I might feel the necessity of the size, complexity, and now importantly, number of hands in the project, increased, but I'm generally a solo developer who maintains long-term relationships with my clients, and I am not building enterprise SaaSes for corporate clients with 300+ users apiece.
In building websites and relatively simple web apps for a smallish businesses. I think we can handle this with our ol' pals HTML, CSS, JS, and a dash of jQuery, for spice.
You'd be amazed what a bit of careful planning can do (while *you* might not, but the kind of dev that decided to learn React *before* JS, might 😳).
Yeah internals documentation is always severely lacking and hopping through them in a debugger is always a mess to mentally untangle.
I completely agree with everything you say. I also don't understand what is going on on some websites when toggling dark mode and the page seems to be doing some heavy stuff while the screen flickers. And all JS should do is add a 'dark' class and store the user's preference. The rest is done with CSS, even to determine the user's OS theme settings.
I also don't understand the purpose of most animations on modern websites, is it really that pleasing to end-users? People should really care more about things like accessibility and performance.
1. An explanation why some websites have dark mode flicker is a when the user selects the "System" option when choosing a theme. The system option automatically follows the user device's color theme and can only be applied by JS when the actual website has loaded. Before the website loads, it will appear in its default theme (usually white) which causes an unavoidable flicker. And yes, this is unavoidable even in a pure SSR or static website.
2. Yes, animations are surprisingly good for increasing your product's value.
@@okie9025you can solve this on SSR, you can save the theme as a cookie and apply it server side
@@okie9025 That's not true, and I don't see the point in repeating what I said in the previous comment.
@@okie9025 CSS has a "prefers-color-scheme" media query, that should resolve immediately before the page is rendered. A script could overwrite that with its own logic, but flickering before going dark is not an inherent part of how the web is designed.
A comment on the animations on the web: It's there for those who appreciates the presentation, especially on the kinds of websites that are trying to be artsy-ish. The animations bring something unique to the idea you're standing behind, whether it's for an art project, or your portfolio.
To quote a comment of my past mentor: "The Web doesn't necessarily have to be fast and optimized, as long as you are satisfied with what you believe in."
As for dark mode, most of the time it's a fancy version of "Telling JS to add some class to some CSS somewhere", with additional project architect complexity. That's how I see it through all of my past projects that touched upon this matter.
_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_
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.
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.
Good to hear voices of reason. I started web development in the 90's, then spent a long time in desktop, mobile and embedded development. When I returned to web, Angular and React were the big new approaches.
First time I tried it I could not believe the amount of installation a new project needed. And the happiness of developers to pull tons of libraries into their projects. Even for the smallest of problems, such as formatting a date, a library was added. And with it a ton of unstable dependencies, increased risk of vulnerability and as you say most of all sluggishness and a ton of code to ship often for no reason at all.
I already fought these symptoms for desktop development, but on the web this is even worse, most likely because most web developers don't know the simple answers to their problems.
But there is an overall tendency by decision makers to go for fast early shipment of a product, rather than neat and speedy code. And most overlook the backpack of problems you gather by relying on libraries that:
- Change often
- Are quickly abandoned
- Give you a headache if you need something outside the feature set of these libraries, i.e. it is usually not easy to just fill a small gap or twist something to your needs
Doing things from ground up only relying on a compact base framework takes longer initially but pays of in the long run.
That is why I am a pure Svelte/SvelteKit user. And I wished some of these concepts would make it into core JavaScript so that we would not need any of these frameworks but had a common ground helping with structuring your dev work (that is mainly how I see Svelte).
they try hard to choke themselves to death
building next floors to a tower with too unstable foundation not seeing the problem is the whole tower itself
and making it standard they keep everyone a hostage of this as companies hate to rewrite anything and start fresh in different technology
things in js world grow like cancer cells
and instead of healing they decide to live with multiple sicknesses calling them not system error but features
I did my webdev bootcamp in 2021 and we learned react, I took time away from programming for health reasons but am getting back into it now. I am so surprised that some of the things we learned in class are already obsolete. It was way easier to catch up and get back into things this time than learning the first time, but it's just been a lot of relearning stuff that doesn't work anymore lol
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.
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
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.
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.
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
Text and layouts load like individual images. That's the problem!
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'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?
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
What do you think about SolidJs, which has 8kb of JavaScript, or Svelte which compiles to vanilla JS?
He doesn't think, this is a rant out of a bad faith argument.
Not sure why this video goes over so many barely connected topics. It should talk about how JS (the programming language) ruined the web, but it talks about:
1. How some nasty websites use too much JS which slows it down (absolutely not a problem with JS itself, and I'd argue this overuse is particularly popular with "classic" devs that use JQuery and WordPress)
2. How some devs use JS frameworks for non-interactive websites (still not a JS problem, and React is not the only JS framework)
3. The npm ecosystem (barely a JS problem, and some full-featured frontend frameworks like Svelte have only 16 dependencies)
4. Performance and load times of websites (true for ordinary JS frameworks, meanwhile every single hybrid/SSR JS framework (like NextJS, which is the *official recommended way to build a React app*) has an entire chapter dedicated to reducing JS bundle sizes, reducing load times, and making sure the website works without JS completely loaded)
5. Hijacking the back button (not a problem with JS)
I also noticed that none of the code in the video is using Typescript, which makes me think that the websites you develop have no more than 1000 LOC. At this point, saying that "JS frameworks are ruining the internet" doesn't mean anything, because the benefit of those frameworks come when your project is made of hundreds of files, tens of thousands of LOC, multiple sub-projects, non-standard data flows (realtime connections), or works in non-standard environments (React-ink for example).
All the people I see complain about programming or Frameworks in general never worked on a big project. You never really understand how good/bad/easy/hard something is unless u do it big. I have a fairly large react codebase that Is a rewrite from using plain js, it is MUCH better both from DX standpoint and performance/UI UX.
@@specy_ Its better for ur usecase. Wont be a universal better solution
Devs add a shitton of ads and trackers, use the wrong tools and write overall bad inperformant code - RUclipsr: 'react makes website slow'
@@moritzschuessler ofc, the use case is having a big project, which a framework makes way easier
Literally the first piece of react code he shows is in TS
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.
"Stuck in the past" back when things didn't suck? Sign me up.
Why won’t build tools delete functions you don’t use so the JS bundle is smaller? There is already one (Webpack tree shaking) but it’s very hard to set up and it can’t optimize away framework bloat.
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.
After checking out some older 90s/early 2000s websites in Web Archive, I noticed how incredibly snappy and simple those websites are, despite Web Archive's servers not having much bandwidth available. Then I started asking myself why websites today are so bloated and perform so bad even on high-end desktop PCs. Then finally found this video. It's a great overview, thanks for that. I can see why it's used(though can't really think of any *good* reasons), but things could be done so much better.
I'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.
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
As someone just beginning to start learning computer science, I think there’s something to be said for learning just what you are actually doing instead of relying on fancy tools. I started programming using python in the terminal! And I learned so much more than if I had jumped straight into something like vs code. Maybe this is because I learned from my dad, who has been in the computing field since the early 80’s and still mainly codes in Fortran using the terminal and text editors
I hate how scripting magic almost entirely eliminated actual website graphics. No matter what page you visit they all look the same. Minimalism my ass, y'all just being cheap and lazy, you bums!
A pure html/css static page can scale well, look modern, be covered in graphics and still be smaller and much faster than a "modern" page only consisting of text and a small logo. Scripting a visual effect may appear more efficient than shuffling bitmap images around, but it's not if you need to pull megabytes of code to make it work.
Html/css is pretty powerful if you have a little patience, and once it works, it's gonna work for years to come. Need more functionality? Sure! Script that and leave the rest alone.
BTW loved your WM setup.
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.
Honestly, the only major things I bothered to learn to improve my webdev experience is figuring out how to make design mockups, vector-based objects and animations for the web in Inkscape, and make portable WebComponents in vanilla JS. Just those things alone (and a healthy dose of borrowing from CSS component libraries big and small) allowed me to keep up with frameworks for the kind of barely interactive websites I get asked to make. Not to mention starting out in a visual-first workspace before writing a single line of HTML makes it easier to come up with a unique, yet still good-looking design. And I can go back to the codebase years later, no problem. Was fortunate enough to never have to deal with Node dependency hell on the projects I had management power over. My custom components are still usable after Angular got replaced by React. And I will still be able to keep reusing them unaffected long after React is gone. I ported entire docs pages over from one framework to another in less than 10 minutes because the entire things were autogenerated from Markdown and LaTeX files. Standards tend to outlive frameworks.
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.
I like opinionated frameworks (i.e. Angular) as it’s efficient for my big team working on a VERY complex application. Angular also comes with a bunch of features and a great CLI tool so life gets easier. Sure, we could do everything in vanillajs but we ain’t got time, deadlines need to be reached and I’ve gotta put food on the table.
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 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
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
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
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.
My angular 16 project produce 600kb js file from 550kb typescript ... not baad not badd :D
12:07 isn't that a problem ? Like I am learning web development and i am told to load the javascript after the html so no problem arrives
Yes, you should load the JavaScript after the HTML, but some JS frameworks initially ship no HTML to the browser and render it all dynamically with the JS framework, which causes issues
Svelte(kit), in my experience, is pretty good. It is a compiler, which compiles to native JS, with no virtual DOM, which improves performance (on avg), as it doesn't have to calculate changes. Also, SSR with SvelteKit hydrates it on the server.
I made my portfolio in nextjs and js ended up being 0,5 mb which is like the size of 10 pictures on my site...
Not to mention that all my npm modules were 400mb combined.
Part of this is also offloading some of the processing power from the server to the client.
reddit's new interface is literally unusable for me. I just don't get it. The old interface displayed 12+ posts at once. The new one shows 2 if you're lucky. Why would they reduce it? Maybe to squeeze more ads in?
Great video! I fully agree with your main points... the web is really a pain to use these days. Although I think you made an incorrect statement talking about Gatsby... You said it has to run javascript before showing any html. But Gatsby generates static pages so that neither the server, nor the client needs to generate the html.. it's served prerendered, which means initial render on screen is really fast. Then it uses JS in the next step to hydrate so of course "time to interactive" could still be sluggish.
That sounds like you fell for marketing talk. If there's another step before payload is displayed, then it's not a static page at all. Whether it's called "hydration" or something else is irrelevant.
Another framework that is part of the problem. If you want the solution, get rid of frameworks entirely!
@@Alien426 Not sure what you are arguing against here... I said that the initial paint is very fast, but that TTI can be sluggish. And don't worry.. I havn't fallen for any marketing talk. I'm speaking from years of trial and error as a frontend developer. In fact I really dislike Gatsby because it's bloated and build times are really bad. All I'm saying is that most of html is served on the first fetch unlike Create React App for example.
...and that the first fetch will be very fast since it's serving a static site, meaning it's actual static .html + .css files on the server, not server side generated markup.
Yeah I thought this was just me. I turn off Java in the settings and websites load in less than a second. But with it on it loads up to 30 minutes and then crashes.
Is interesting listening this point, because mainly your point is "SPA = bad" (is an oversimplification), but there is a lot of resistance to going back to fully SSR and do less things on the client.
I am looking into building my own website and with all the tools out there it gets overwhelming and since I'm primarily a back end developer all the UI stuff is hard to navigate. I just want a simple website that my wife can update. I have tried word press and it is okay but I haven't messed with php in over a decade. Any advice on what tools to use?
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
Next js with ssg serves pages super fast… wdym?
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.
Just curious as a person who isn't in web development, why would you need to create a website using a framework even if it does simplify the process of building it, couldn't you just build... the whole website yourself without having to make those performance sacrifices? I know that maybe for certain features like support chats, or social features like messaging or even more complex features, I would understand using a framework. But for everything else not a whole lot.
fwiw you should expect breaking changes from a new release major if the software is versioned with SemVer. that is what the major release is for.
your seamless portfolio written in plain JS, html and css, that helps you land a job as React developer😊.
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
Web developers don't use web frameworks because they are new and trendy. They use them because they actually solve many problems.
You said
3:17 These new frameworks aren't even better than the old way.
You are wrong. They are better!
Web developers are not idiots to do new things just because they are fancy.
Most websites are janky because the Ads those websites are running.
I partially agree with your point at 4:25 that static sites don't need React (or other frameworks). Yeah! Unless you are not posting frequently on your blog site.
If you are, then you only have two options:
1. Generate your blog pages with a templating system. ( Server Side Rendering or pre-rendering)
(or)
2. Fetch your latest post from some backend and render them dynamically (in the frontend)
Do you want to receive comments from your readers? 😂
That's a whole another game!
For example look at 'MDN Web Docs'. Their new site is made with react!
Many websites run slowly because of poor ENGINEERING.
There are many examples for extremely complicated sites running buttery smooth, but instead you are exaggerating the negative parts of the modern web.
I think you might like Svelte or LitElement.
JavaScript did not ruin the Modern Web.
I don't want to watch this video on a desktop app instead of a browser
i actually laugh when u used recipe and newspaper sites for the poor performance of frameworks. These sites intentional load a shit ton of ads and trackers. Thats the thing that takes a year to load.
Totally agree with you that the frameworks are used for the wrong use cases. A static website doesnt need to use react. The dev decided to because he wanted to
I 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.
In my experience, modern "UX design" is a huge part of the problem.
I like to create projects with Vanilla JS and simple CSS.
But, the main reason I learned React is for the JSX. So much simpler and intuitive. Also I need to eat.
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'm a web dev for a really big e-commerce site and I can tell how to fix your problems
slow initial load: use react lazy loading (works for both SPA, SSG and SSR sites).
bloating: use svelte/vue/preact instead of react. stay away from frameworks like gatsby, angular they're known for bloating.
css bloating: use postcss to cleanup unused css, tailwind comes with builtin postcss and is like bootstrap but better.
back button: works as expected in SSR and SSG, but in SPA you've to write extra logic, so that user scrolls back to same position from where they left
dev experience: I agree it sucks. my project takes 30 mins to start in local dev server, because first typescript is transpiled to js, and next js uses webpack which is slow these days because it uses Node.js internally. They're working with the Rust version but it's not compatible with the babel plugins that most next js project uses.
I am SAPUI5 developer - i got a task to develop a Fiori app which would change column amount dynamically - user could select 1-x amount of column and these columns should have data aggregated by days or weeks or years. Yeah - oData cannot be extended like that so I was doing it in JS. Imagine how big could app get before I generated everything over there. A nightmare
"Just get a better computer bro"
😂😂
If you can't build a webpage in under 50KB including ALL your scripts, you're incompetent. That JS bloatware needs to die.
I'd be interested in hearing your take on the Astro framework. It seems to combine the best of both worlds by allowing static site building, hydrated framework components if you want them, and even an SPA mode if you really want it now.
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...
At work, we use Django in the Backend and mostly vanilla JS in the frontend. (Django by default comes with a jQuery installation, but if you don't use that it won't be loaded.)
I 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.
The problem: so you want interactivity but you don't know exactly when, where and how much ? well you could just use vanilla js but that's a bad experience, so instead just use a framework for SPAs by default. Whose fault is it ? and why is it not the browser vendors' fault for refusing to evolve into what 95% programmers are doing ?
The problem with these frameworks is that js was never meant to be a language to do rendering with, it's just not fast enough. But with native (at the browser level, in C++) implementations of react you could do sooo much better probably 100x improvements
Reddit is doing something wrong definitely because you can make the same thing in Vue as an SPA and it'll run blazing fast. Proof is there are (or at least were) third party SPA reddit clients and they run super fast.
Reddit is here to spy on you not to help you in any way
it's slow for a reason
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
Design your code for your use case. Frameworks can often make development and maintenance much easier and therefore for small apps they can be preferable.
It's a similar debate to monolith vs microservices, or Kubernetes vs bare metal servers. There are pros and cons; feature differentials; maintenance and development considerations; even business cases etc. that all need to be considered, and being dogmatic or famatical about any given approach is usually detrimental to the end result. You'd never make a full enterprise system with a lot of data dependencies as a pure microservices design due to performance considerations, but microservices are great for developing and maintaining simpler product stacks, for example.
Build for your use case; not for what you see as ideal.
Q: my current site is built off WordPress (because I'm a know-nothing n00b who never learned anything past HTML2). My website is literally just a few posts (because I'm too lazy to post more often), a portfolio of my best art (which ain't that great), and that's about it: just text and images. Would I be able to build something faster with Hugo?
Yep, I think Hugo would be a good choice for you. It's more complex than just using simple HTML, but it's not that difficult to wrap your mind around. I have a few old videos about it you can search up.
@@EricMurphyxyz Thanks! :D I'll give 'em a glance!