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.

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.

code of conduct - report abuse