re: The Web I Want VIEW POST

VIEW FULL DISCUSSION

Ha! As the saying goes: the road to hell was paved with good intentions. This is a very technical perspective of a much more complex issue. I 100% agree that we get bombarded with too much code from nearly every website out there, but the fact that advertising and user tracking directly effect the revenue of most companies, especially media companies, means this problem isn't going away anytime soon.. and probably never will. I recently read an essay about "the Bullshit Web" (pxlnv.com/blog/bullshit-web/) that goes much deeper into the real problems of the internet economy. The fact that there are companies that exist solely to provide advertising and user stalking services should be enough to help us understand why "modern" websites are so code-heavy. It's all about the data; or getting as much data from users as possible... and monetizing it. And unless you own the company, you, the developer, probably have no say in what advertising technologies get forced upon you no matter how much you push back.

As a user, the only thing to do is unplug or find websites with different agendas than showing ads and monetizing user data. The latter means you will probably have to pay a subscription fee, but that is the trade-off for not getting bombarded with ads. Even then, these subscription websites still need to track usage for many good reasons, like improving content and usability so there will always be a need for some sort of tracking code.

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. 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. Picking the right tools for the right job is the first decision to make when planning a project. Then do your best with what you have to work with to make the website as usable as possible.

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.

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.

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.

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.

You do not need a frontend framework for a website with huge amounts of content.

You need a database for a website with huge amounts of content, but those run alongside your web server. Wordpress sites don't need JavaScript. DEV will happily show you the content with JavaScript disabled. You can run a Google search with JavaScript turned off, too. You don't need JavaScript to have a database-driven app.

JavaScript benefits come in when you're coming up with ways to present or edit the content that aren't already built-in to the browser. "Like Button" flows where you click a button and it does the actual work in the background without a progress bar are a JavaScript benefit. So are Google Maps and other "infinite scrolling" sites, WYSIWYG editors, and shims for new standard features that the browser doesn't implement yet.

code of conduct - report abuse