As for the pokes at using "vue/react/whatever", if you're building a 5 page website, then maybe you don't need a framework... I'll give you that. But these frameworks have their place - mainly for websites with tons of content.
Why does a website with tons of content require a frontend framework ?
It's this kind of advice that I am rallying against because it's just not true.
By taking this kind of advice people are hiding content from people who can't or won't run JavaScript in the browser.
I wouldn't want to build html pages for every recipe on a website with over 1 million recipes or a TV network website with 50+ years of TV show content.
Neither would I. I'd have the stuff in the database and then I'd write a tool that would generate the pages and then ship them. Easy, accessible and fast.
Why does a website with tons of content require a frontend framework ?
It's this kind of advice that I am rallying against because it's just not true.
It's not a requirement; it's a choice; it's a tool. Like I said before, it's all about choosing the right tool for the right job.
SPA frameworks in particular are good on slower connections because the browser does most of the work up front to load the page structure and resources. Then the page only needs to load new content for the user. Loading less code for each page request is better than loading the entire page and its resources for every request. (I get that you are saying there's too many resources, but I answered that in my first reply)
By taking this kind of advice people are hiding content from people who can't or won't run JavaScript in the browser.
(regarding sites with lots of content) Neither would I. I'd have the stuff in the database and then I'd write a tool that would generate the pages and then ship them. Easy, accessible and fast.
This is exactly what happens on every enterprise website that uses a front-end framework. The difference is in my answer above.
If you don't want or can't run JavaScript, then you probably won't be able to get 99% of the content on the web. This is just simply a fact. Unless companies stop making money because they don't accommodate people who don't run JavaScript in their browsers, then that won't change.
The good news is that people are starting to fight back against all the ads and trackers. This is starting to have impact companies' bottom lines so maybe we are at the beginning of a shift in how websites are built. At the very least, I'm hoping the ad and tracking companies will get on the ball to make their code better, more efficient. Some libraries out their are ancient in web years so getting them to use modern code and techniques is probably half the battle.
I will also add that some legacy sites I've worked on without frameworks had tons more JavaScript code than some more recent projects I've built with frameworks. When used properly, frameworks can be very beneficial for code management.
If you don't want or can't run JavaScript, then you probably won't be able to get 99% of the content on the web.
Really? Try it - you might be surprised. Twitter works nicely, Gmail works nicely. And these are 'web apps'! It's amazing what you can get done with a few forms and REST.
SPA frameworks in particular are good on slower connections because the browser does most of the work up front to load the page structure and resources.
I can imagine a saving on slower connections - but only if your objective is to shift 100s of MB of scripts, images and other 'resources' to the user. I can't see there being much of saving for serving plain ol' HTML.
And it's not like that saving is without consequence. It's going straight down to the client's browser, sucking up cycles until you can hear the fan taking off. Crashing the browser, crashing the computer... and for what? For reading a damn recipe?
I read once that you can divide web developers into two camps: you either think a web browser is an HTML document viewer, or you think it's a platform for JavaScript applications. Maybe that's a lot of the disagreement here. For me, if something is a page, a document, a thing that people read, then the web is already the perfect platform to view it - from the URL all the way down to the section tag. Why mess with that?
I read once that you can divide web developers into two camps: you either think a web browser is an HTML document viewer, or you think it's a platform for JavaScript applications. Maybe that's a lot of the disagreement here.
I think this is very insightful.
I do think it can be both (although it's waaaaay better and easier as a document viewer) but the problem is people are too often making "applications" out of recipe books, blogs, etc.
We've been messing with that since we started viewing pages in Netscape Navigator. That is where JavaScript came from in the first place.
Web browsers are content delivery applications. That content can be in many forms: html, text, video, binary files, etc. You're assuming that everyone has the same goals for having a website. If I just want you to read text, then I might not have any JavaScript on the site. But if I want to serve content within a particular context or format, then I might need to write some code to handle that.
There are trade-offs for every decision made for a web project. Those decisions are made according to the business goals. If, like twitter and Google, your goals are to serve the most users as possible, then you must build the site to work without JavaScript. There's still a trade-off, though, since some of the functionality will not work without JavaScript and the extra time it takes to build, test and manage a site like that requires a significant investment which not every company can afford.
Look at other sites where people spend a lot of their time: Facebook, Netflix, YouTube, etc. Try using any of those without JavaScript. Actually, some recipe sites are good examples of having just enough script to solve some business requirements (including ads and tracking), but they still work without it. If you search for "general tsos chicken," most sites in the results will at least show the ingredients and directions - some better than others.
Well yes, no one can disagree with "there are trade-offs to every decision you make... sometimes you need javascript to do x y z"
The point is that too many people are making the wrong choices and are inflicting JS where it isn't needed.
But I'm not just talking about JS. Too many images, requests for other resources, make websites needlessly slow.
Most of the tutorials you will see on this website are about using react/vue/whatever but very little seems to be dedicated into the art of making your website performant and accessible with simple technologies; and that is reflected on a lot of the internet today.
Part of the purpose of frameworks like Vue, React, Angular, etc., is to make sites more performant as well as manageable. There's a ton of info about improving performance out there. Just follow people like @addyosmani
, @paul_irish and @lukew to name a few. This site is new so give it some time and you'll start to see more content like that. Heck, you should write about the things you do to boost performance on here. You might just start a trend or at least spark some interest in others to do the same. :)
I just finished rebuilding a legacy app in Vue.js. It contained ~30 pages and was basically just a super long form.
The change in performance between an ASP.NET MVC view rendered with Razor and one rendered as a SPA in Vue was staggering. The entire app weighs in at only 450kb and page load times went from an average of 3 seconds, to 500ms. It's also a billion times more maintainable.
So it was taking three seconds to load a form. Thirty pages of forms were taking on average three seconds. So some of them were taking longer than three seconds to load. To load an HTML form.
Look, I'm not doubting that you got a huge performance boost by moving to Vue. Great work!
I'm just wondering what the original version was doing to take so long to render a form.
Several large JS and jQuery libraries were being loaded to perform specific validations, masking and calculations of card numbers and other input events, of which 90% of the library was unused. Also, since the page now loads the view model asyncronously on load via AJAX, rather than binding directly to it via Razor, there's no render blocking happening.
SPA frameworks in particular are good on slower connections because the browser does most of the work up front to load the page structure and resources.
I must be missing something here, because for a sane content oriented site, page structure should not be much larger than the content, and resources would be cached.
Also, it takes time to load the stuff up front, so you're trading speed of second and later page loads for the speed of the first one. That is not necessarily a good trade-off.
You totally should. I would read it. People freak out over this.
There are a handful of fast languages, Go, Elixir etc.. that are excellent at rendering html very quickly. For slower languages, using simple caching can speed things up considerably as well as optimizing queries using EXPLAIN in sql.
And PHP is GREAT at that, which is why WordPress is built on PHP. I love PHP, for all its flaws, I absolutely love the language. Of course, it's trendy now to throw PHP under the bus for front and backend frameworks, all the way from React to Node, which is insane to me since JS was never intended to be a backend language.
Right there with you, you don't need a framework to build your own engines for things and engineer simple automation. (template, layout, router, adapter for outside world stuff, state machine, etc...) build what you need as you need it and grow.
In fact I think of frameworks as just a collection of libs that share a common DSL. This comes at a price which is that is each lib tries to be all things to all people and all types of apps, at scale. Also React solved problems at Facebook, and Facebook alone. Facebook's solutions are not the right solutions to every component content based web/mobile app especially at scale.
I have seen every type of app go off the rails over my ev life. From vanilla coupled based JSP apps, to JQuery craziness, to Bootstrap spaghetti code for years, to Wordpress templates from hell (even from Themeforest), to Angular and React projects that were overcooked very early on and never looked back until they reached a point could not longer refactor the spaghetti ball anymore. The problem is never the code, and never the framework. If a codebase get's derailed, people did that, not React.
Rolling your own means you only make what you need and nothing more. Your app stays lean, your code stays cleaner, your team is happier because it's easier to work on, its future proof, no need to wait for Meta to wrap that new web API in a React renderer. It's more secure. You have finer detailed control over your business use cases.
It forces you to use the new Web API's and vanilla API's properly instead of hacking your way around them because the framework's worker procedures don't support them yet. The virtual DOM, if it finds a diff, still touches the real DOM 100% of the time, every time. So what's faster than accessing the DOM alone? nothing. What's faster than GPU enhanced animations via CSS3 matrix 3d transforms? Nothing. What's faster than pure vanilla Web GL and canvas API? nothing.
So now what happens when you abandon frameworks from your mental model? You start to optimize the fact that you are now responsible for all the pieces your framework was previously accounting for. You will be surprised at the differences in every way. Try it with one app to cut your teeth, and just experience what its like to build your own router, build your own ports / adapters, build your own html generator, or page layout engine, markdown parser, build a virtual DOM diff engine. But build them so they are just enough for your needs, and nothing more, then use them and see how light it feels.
I started with JS about 10 years ago and I fell in love with it (even though it can be weird 😅). I had step backs in my career that ended up being good. Currently I'm a passionate front-end developer.
Often, many libraries or frameworks tend to over bloat an app with a ton of unnecessary code that the browser has to parse and deal with.
I feel that it is better to grab a few well tested libraries and implement them in a project... however I recently started to use Svelte cause it gives like the best of both world I guess, haha, but still, no framework is perfect, so I do get one complication occasionally when using it.
What is your opinion on these type of frameworks? That, unlike others, they just ship a small amount of extra code to your built app.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why does a website with tons of content require a frontend framework ?
It's this kind of advice that I am rallying against because it's just not true.
By taking this kind of advice people are hiding content from people who can't or won't run JavaScript in the browser.
Neither would I. I'd have the stuff in the database and then I'd write a tool that would generate the pages and then ship them. Easy, accessible and fast.
It's not a requirement; it's a choice; it's a tool. Like I said before, it's all about choosing the right tool for the right job.
SPA frameworks in particular are good on slower connections because the browser does most of the work up front to load the page structure and resources. Then the page only needs to load new content for the user. Loading less code for each page request is better than loading the entire page and its resources for every request. (I get that you are saying there's too many resources, but I answered that in my first reply)
This is exactly what happens on every enterprise website that uses a front-end framework. The difference is in my answer above.
If you don't want or can't run JavaScript, then you probably won't be able to get 99% of the content on the web. This is just simply a fact. Unless companies stop making money because they don't accommodate people who don't run JavaScript in their browsers, then that won't change.
The good news is that people are starting to fight back against all the ads and trackers. This is starting to have impact companies' bottom lines so maybe we are at the beginning of a shift in how websites are built. At the very least, I'm hoping the ad and tracking companies will get on the ball to make their code better, more efficient. Some libraries out their are ancient in web years so getting them to use modern code and techniques is probably half the battle.
I will also add that some legacy sites I've worked on without frameworks had tons more JavaScript code than some more recent projects I've built with frameworks. When used properly, frameworks can be very beneficial for code management.
Really? Try it - you might be surprised. Twitter works nicely, Gmail works nicely. And these are 'web apps'! It's amazing what you can get done with a few forms and REST.
I can imagine a saving on slower connections - but only if your objective is to shift 100s of MB of scripts, images and other 'resources' to the user. I can't see there being much of saving for serving plain ol' HTML.
And it's not like that saving is without consequence. It's going straight down to the client's browser, sucking up cycles until you can hear the fan taking off. Crashing the browser, crashing the computer... and for what? For reading a damn recipe?
I read once that you can divide web developers into two camps: you either think a web browser is an HTML document viewer, or you think it's a platform for JavaScript applications. Maybe that's a lot of the disagreement here. For me, if something is a page, a document, a thing that people read, then the web is already the perfect platform to view it - from the URL all the way down to the
sectiontag. Why mess with that?I think this is very insightful.
I do think it can be both (although it's waaaaay better and easier as a document viewer) but the problem is people are too often making "applications" out of recipe books, blogs, etc.
We've been messing with that since we started viewing pages in Netscape Navigator. That is where JavaScript came from in the first place.
Web browsers are content delivery applications. That content can be in many forms: html, text, video, binary files, etc. You're assuming that everyone has the same goals for having a website. If I just want you to read text, then I might not have any JavaScript on the site. But if I want to serve content within a particular context or format, then I might need to write some code to handle that.
There are trade-offs for every decision made for a web project. Those decisions are made according to the business goals. If, like twitter and Google, your goals are to serve the most users as possible, then you must build the site to work without JavaScript. There's still a trade-off, though, since some of the functionality will not work without JavaScript and the extra time it takes to build, test and manage a site like that requires a significant investment which not every company can afford.
Look at other sites where people spend a lot of their time: Facebook, Netflix, YouTube, etc. Try using any of those without JavaScript. Actually, some recipe sites are good examples of having just enough script to solve some business requirements (including ads and tracking), but they still work without it. If you search for "general tsos chicken," most sites in the results will at least show the ingredients and directions - some better than others.
Well yes, no one can disagree with "there are trade-offs to every decision you make... sometimes you need javascript to do x y z"
The point is that too many people are making the wrong choices and are inflicting JS where it isn't needed.
But I'm not just talking about JS. Too many images, requests for other resources, make websites needlessly slow.
Most of the tutorials you will see on this website are about using react/vue/whatever but very little seems to be dedicated into the art of making your website performant and accessible with simple technologies; and that is reflected on a lot of the internet today.
Part of the purpose of frameworks like Vue, React, Angular, etc., is to make sites more performant as well as manageable. There's a ton of info about improving performance out there. Just follow people like @addyosmani , @paul_irish and @lukew to name a few. This site is new so give it some time and you'll start to see more content like that. Heck, you should write about the things you do to boost performance on here. You might just start a trend or at least spark some interest in others to do the same. :)
I just finished rebuilding a legacy app in Vue.js. It contained ~30 pages and was basically just a super long form.
The change in performance between an ASP.NET MVC view rendered with Razor and one rendered as a SPA in Vue was staggering. The entire app weighs in at only 450kb and page load times went from an average of 3 seconds, to 500ms. It's also a billion times more maintainable.
That’s awesome!
So it was taking three seconds to load a form. Thirty pages of forms were taking on average three seconds. So some of them were taking longer than three seconds to load. To load an HTML form.
Look, I'm not doubting that you got a huge performance boost by moving to Vue. Great work!
I'm just wondering what the original version was doing to take so long to render a form.
Several large JS and jQuery libraries were being loaded to perform specific validations, masking and calculations of card numbers and other input events, of which 90% of the library was unused. Also, since the page now loads the view model asyncronously on load via AJAX, rather than binding directly to it via Razor, there's no render blocking happening.
I must be missing something here, because for a sane content oriented site, page structure should not be much larger than the content, and resources would be cached.
Also, it takes time to load the stuff up front, so you're trading speed of second and later page loads for the speed of the first one. That is not necessarily a good trade-off.
Indeed
I feel like I could write another post entirely about the fetish of initial page load at the expense of the performance of everything else.
You totally should. I would read it. People freak out over this.
There are a handful of fast languages, Go, Elixir etc.. that are excellent at rendering html very quickly. For slower languages, using simple caching can speed things up considerably as well as optimizing queries using EXPLAIN in sql.
And PHP is GREAT at that, which is why WordPress is built on PHP. I love PHP, for all its flaws, I absolutely love the language. Of course, it's trendy now to throw PHP under the bus for front and backend frameworks, all the way from React to Node, which is insane to me since JS was never intended to be a backend language.
Hey! just saw that you love PHP, I also want to learn it, can you provide me a good resource.
Look at phptherightway.com/
Right there with you, you don't need a framework to build your own engines for things and engineer simple automation. (template, layout, router, adapter for outside world stuff, state machine, etc...) build what you need as you need it and grow.
In fact I think of frameworks as just a collection of libs that share a common DSL. This comes at a price which is that is each lib tries to be all things to all people and all types of apps, at scale. Also React solved problems at Facebook, and Facebook alone. Facebook's solutions are not the right solutions to every component content based web/mobile app especially at scale.
I have seen every type of app go off the rails over my ev life. From vanilla coupled based JSP apps, to JQuery craziness, to Bootstrap spaghetti code for years, to Wordpress templates from hell (even from Themeforest), to Angular and React projects that were overcooked very early on and never looked back until they reached a point could not longer refactor the spaghetti ball anymore. The problem is never the code, and never the framework. If a codebase get's derailed, people did that, not React.
Rolling your own means you only make what you need and nothing more. Your app stays lean, your code stays cleaner, your team is happier because it's easier to work on, its future proof, no need to wait for Meta to wrap that new web API in a React renderer. It's more secure. You have finer detailed control over your business use cases.
It forces you to use the new Web API's and vanilla API's properly instead of hacking your way around them because the framework's worker procedures don't support them yet. The virtual DOM, if it finds a diff, still touches the real DOM 100% of the time, every time. So what's faster than accessing the DOM alone? nothing. What's faster than GPU enhanced animations via CSS3 matrix 3d transforms? Nothing. What's faster than pure vanilla Web GL and canvas API? nothing.
So now what happens when you abandon frameworks from your mental model? You start to optimize the fact that you are now responsible for all the pieces your framework was previously accounting for. You will be surprised at the differences in every way. Try it with one app to cut your teeth, and just experience what its like to build your own router, build your own ports / adapters, build your own html generator, or page layout engine, markdown parser, build a virtual DOM diff engine. But build them so they are just enough for your needs, and nothing more, then use them and see how light it feels.
Really interesting point of view!
Often, many libraries or frameworks tend to over bloat an app with a ton of unnecessary code that the browser has to parse and deal with.
I feel that it is better to grab a few well tested libraries and implement them in a project... however I recently started to use Svelte cause it gives like the best of both world I guess, haha, but still, no framework is perfect, so I do get one complication occasionally when using it.
What is your opinion on these type of frameworks? That, unlike others, they just ship a small amount of extra code to your built app.