loading...

The Web I Want

quii profile image Chris James ・6 min read

This post will very much sound like I want you all to get off my lawn - because I do.

How has the web become like this?

From this very website

The other day my partner was browsing the web on her two year old Chromebook, it struggled to run a number of sites as they loaded ads, gifs, videos and tons of JavaScript to do absolutely nothing of value.

Every day I am frustrated at my phone as it chugs along trying to display a blog post. The post is there behind a sea of JavaScript and auto-playing videos.

This all sounds a bit first world problems, but it's far, far worse for those in developing nations. Do you know how bad satellite Internet is compared to what most of us have here in the west? It is awful.

Mobile connection speeds

The World Wide Web is supposed to be a leveler, something that brings knowledge everywhere and yet developers every day are making it harder for those who need the Internet to work well the most.

Let's take a look at how things have "progressed" with the Internet.

20ish years ago

I made my first website about 20 years ago and it delivered as much content as most websites today. It was more accessible, ran faster and easier to develop then 90% of the stuff you'll read on here.

20 years later I browse the Internet with a few tabs open and I have somehow downloaded many megabytes of data, my laptop is on fire and yet in terms of actual content delivery nothing has really changed.

Technologies used:

  • HTML

10-15 years ago

People were fed up of nested tables and spacer images. The web was losing its roots of being a content delivery platform.

I was working on websites like the above in my placement year on my degree. I started reading articles on A list Apart about how we should be pushing for semantic markup, where HTML simply describes a document of content and then it is styled using this thing called CSS.

Eventually I ran into CSS Zen Garden which is a website that showcases what you could do with CSS.

The idea is the markup is the same and the website has submissions from developers showing different designs purely using CSS.

The HTML remains the same, the only thing that has changed is the external CSS file. Yes, really.

This website had a profound impact on my attitude to web development. It clicked. HTML for content, CSS for style. No JavaScript required, no tables needed for layout, no spacer images.

Just pure HTML decorated with CSS.

It felt exciting to be part of a community that took real pride in delivering beautiful looking content in the leanest, simplest and most accessible way possible.

Not only did this make websites more accessible and fast to run but in some ways made them easier to develop. Suddenly generating the markup from the server wasn't horrible!

Still things were quite difficult. CSS support wasn't amazing and we still didn't have a lot of semantic elements with HTML4 so there were a lot of divs. Firebug had just come out which was a huge boost but it was still hard to make a consistent experience.

I seem to recall Gmail coming out around this time and it was amazing. Suddenly the web could be actual applications. This is interesting and groundbreaking, but had a real negative impact too. Soon enough people thought that the promotional website for their local pub had to have as much JavaScript as Gmail.

5 years-ish till present

Here is a not exaggerated summary of today's attitudes

Scores of people who just want to deliver their content and have it look vaguely nice are convinced you need every web technology under the sun to deliver text.

You're not a frontend developer unless you know Vue/React/whatever. You're mocked if you dare to just write the bare minimum JavaScript you need for your website

The page refreshing is seen as a massive problem for users, and it must be avoided at all costs.

For some reason people are building tons of SPAs (single page web apps). The reasons stated are for speed and ease of developer use. (I don't buy sending tons of JavaScript to a browser will ever be as fast as just some damn HTML. Also it's not as easy as putting some HTML files on the Internets)

You see these laughable posts where developers jump through dozens of hoops to make their website "fast and performant". They struggle because of the underlying technical choices and then I'm still downloading half a megabyte of data to read 500 words. It's embarrassing.

There are a few things I want you to take away from this post

  • Most websites are about delivering content. HTML is amazing for this and you don't need JavaScript.
  • In fact JavaScript is actively harmful. It is poison for low power devices, horrible for people on low bandwidth and requires extra effort to keep it accessible and fast.
  • So much effort poured into all this JavaScript. You seem to have to learn so much, new frameworks, new build tools, new ways of testing; and most of the time it is making the experience worse for your users.
  • In practice your website would do everything it needed to with some HTML files linking to some CSS.

So what is the The Web I want

  • Semantic, accessible, HTML. This means it works for everyone, is fast to download and is less effort than writing React components.
  • CSS to make it look pretty. Dont use JavaScript for visual effects.
  • Small images, when needed. Enough of these hilarious 4mb GIFs.
  • Most websites should be ready to read after a 10kb download.
  • If I cant use your website without JavaScript being turned on then you don't know what you're doing.

So no JavaScript, really?

JavaScript of course still has its place and when used tastefully can improve the usability of a website. However think carefully about the libraries and frameworks you pull in. Maybe you can accomplish what you need without bringing in JQuery, modern browsers have excellent APIs built in these days. Aim for progressive enhancement with JS. Your website should still work without JS turned on.

Regarding single page apps (SPAs), I genuinely believe too many people are making them. GMail is a web application and as such deserves a framework. Your blog platform? Not so much. Remember these frameworks not only put a lot of strain on user's experience but it's also just a lot to learn. Maybe your time could be served better.

But my product owner says we need all these bells and whistles!

As a professional, it is up to you to take a stand. You are the expert, not the customer.

  • You should be informing them how Amazon learned that every 100ms in page load cost them a 1% of sales.
  • You should be informing them that making a carousel of their product catalogue is slow and annoying and expensive to make compared to just listing them in a <ul>.
  • You should let them know that if they really want their groundbreaking poetry to reach around the world that they better make sure their website works on old hardware with slow Internet connections.

If I told the builder of my home to make it out of straw, I would hope she would convince me otherwise.

Of course, circumstances are tricky and sometimes people will ignore you but when you look at the state of some of the popular websites today you can only conclude that people either don't know what they're doing or are just not pushing back on bad requirements enough.

Wrapping up

Take a look at the performance tab in developer tools for your website. Does it make you proud? If not, take some pride and start cutting away the cruft you thought you needed.

Let's take pride in making lean, accessible, simpler to execute websites by using simple technologies that work everywhere. There are moral and technical arguments for taking this approach.

Remember that the goal of most websites is delivering useful textual content, and all you really need for that is HTML.

Then we might not have to buy new laptops every 2 years and people less fortunate than you have a chance of actually using the web; the way it was intended.

Posted on Aug 20 '18 by:

Discussion

markdown guide
 

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.

 

I agree with you, but we need to remember why the web has become such a mess: Marketing "experts" (the forefathers of "SEO" scoundrels) have seen the rise of new technologies, and while Gopher and Usenet don't actively support advertising (no embedded images, no scripting), the web was a perfect victim. This is only one of the reasons why I actively spread the word that both the Usenet and Gopher are still around: they are still not flooded with blinking annoyances. I would write an article about that, but Cameron Kaiser has already done that.

 

I agree with the sentiment: we can and we need to do better.

I do remember the days of A list apart, CSS Zen Garden and Eric Meyer's website :D

I'm not tranchant on JS, I don't think the solution is to not use it, we're definitely past that. The solution is to stop and think about what we're doing :-) I wrote only one SPA and it's an "internal" application for a client which is never going to be Internet facing or public but I did notice how low the score with Lighthouse is :-)

Many CMS are also full of JS and a lot of websites are generated by CMS. Fortunately (also thanks to this influx of JavaScript) I see a growing interest in static websites generated by headless CMS.

You're going to love this: The Cost Of JavaScript In 2018 by Addy Osmani - the beauty of this article is how thorough and deep it is and how he considers the average phone as a benchmark reference.

I still don't know enough to have an definitive opinion on this topic but we can all agree that sending 2mb of JS to a person on 2G or 3G is unwise.

ps. dev.to is a SPA but I tried to write and post this comment after disabling JavaScript on Firefox (whose setting is buried in about:config :D) and I got an error, which is fine, SPAs are not supposed to work without JS...

 

I do remember the days of A list apart, CSS Zen Garden and Eric Meyer's website :D

It was so good, it felt like a real positive movement for the web

ps. dev.to is a SPA but I tried to write and post this comment after disabling JavaScript on Firefox (whose setting is buried in about:config :D) and I got an error, which is fine, SPAs are not supposed to work without JS...

I do mean to host this post on my own blog when I get home!

 

I basically agree with all of what you said. We made some pragmatic choices along the way to serve an experience which mostly works and serves an efficient experience for 95% of requests.

Not to defend the bad, but things are overall pretty okay. Specifically, the chat feature and other generally "live" features are pretty much entirely responsible for some of this JS dependence.

Anyway, you'd be happy to hear that now that we're open source, we're pruning some of the bloat that kind of just made its way in when we were pushing a bit too hard to cram in the features folks were demanding. Our approach has returned to a much more principled one.

Anyway, just wanted to address this from my perspective. I'm spiritually aligned, but we've got some work to do. Eventually I'd like to offer various configurations that would allow folks to turn off certain features in order to run differently in different scenarios.

:)

 

Http is at fault not JavaScript. That's all about to change.

That said, today, where I work we sit behind a fairly hefty cache and CDN, the attitude is just cache what we can and returning visitors will have fast page loads, that's wrong and presumptuous in my opinion.

 

Where I work our approach is similar, except we also put everything on the edge that we can, and use some proprietary stuff we built to keep us in sync

 

Hefty caching and CDN are great tools and mitigate the problems but the problem of CPU time running all that code doesn't go away.

 

I'd say that the perception of speed is far more important than actual fast code, cached or not. What your talking about is user experience after the fact. Keep calm and lazy load, defer and look at script attributes. Take charge and don't trust browsers. Until multiplexing http2 arrives that is.

 

I completely agree that JavaScript is massively overused these days. Speaking of Amazon, most of the time the page loads and I'm still waiting another 10-20 seconds for all the JS to finish loading (Win 10, AMD FX 3ghz, 16GB DDR3, broadband connection - it's old, I know... new build this week). I run a blog about sports. I have writers and advertisers (not just AdSense and the like), and I have a million readers. I use a simple theme, though its JS use still brings my pages over 1MB in size (3MB is the average). That's for text mostly, with a featured image (paid optimizing service for all images) and an embed or two. Thankfully, my target audience is almost exclusively in the US.

While I agree that some features built with JS are fun to look at, I'm amazed every day at the utter lack of function in most of them. It's wasteful.

I think your article focused too much on the developer side of things in that all this JS is more difficult and time consuming. It may be true, but it's also not the point. JS is most often bad for users. About the most I can stand JS is for AJAX page loads and sometimes menus too, though most of those can be done with static markup.

First time on this site. Great article. Thanks.

 

Thanks

I definitely was trying to draw the parallels that it all can both be a lot of effort for developers and can make the experience worse for the devs :)

 

Of course. But you know how these devs are when you go after their precious JS; they'll take any excuse to call you lazy or an inferior developer.

One thing I wanted to add is why I disagree with JS so much: JS offloads page loading to the user's browser, freeing up the server. Seems cheap to me, and makes my browser work harder than it needs to. When it's for personalization, alright, but most JS use isn't for that purpose.

 

First:

Congratulations for this excellent write up.

Second:

I use Steven Black Hosts project on all my computers to forbid lots of stuff to load on my browser, as result i have better load times in all web pages I visit.

Third:

Server side rendering html is enough for a huge majority of web pages we see out there and if developers would stop to use their fancy machines to run their javascript and instead would use very old computers they would understand why they should use javascript wisely.

Plus nowadays we already have server side technologies that can render complex html pages in microseconds... yes microseconds, not milliseconds. This is achievable in Elixir with the Phoenix framework. The html engines concatenates the strings to build the html in the http stream that sends the data into the browser, not in memory as any other program language does. See this article for more details.

Phoenix even have server side dom manipulation that avoids the use of tons of javascript on the client side to achieve it.

Watch this video to see how server side dom manipulation can scale for concurrent usage with a demo that runs at 60 fps .

 

Thanks for the kind words

Elixir & Phoenix has been on my radar for a long time but honestly most people don't even need that kind of response times; even a "slow" server side language like Ruby is fast enough for the majority of cases.

That's what makes it all so ridiculous, its easy to make fast accessible websites if you make simpler choices.

 

Elixir & Phoenix has been on my radar for a long time

Time to look into it and I strongly recommend anyone to start with PragDave books or courses and just after to learn how to use the Phoenix framework.

even a "slow" server side language like Ruby is fast enough for the majority of cases.

I can agree with you on that any language can server server side rendering fast enough for a lot of use cases.

But for the ones that defend the use of Javascript frameworks due to faster speeds, specially on busy servers, than the solution is Elixr, because is the only language built from scratch to be concurrent, distributed and fault tolerant.

To note that I agree that full Javascript frameworks have their use cases, unfortunately the majority of the times they are not the best tool for the job... but they are a trend, thus it looks bad if one thus not go with the flow ;)

 

As a back end developer who is trying to learn front end development this caught my eye. I'm curious how you would accomplish things like drop-down menus that "mobile first" sites have these days. At this point in my journey I'm not aware of any way to take action on a click other than JavaScript (form submit and links aside of course).

 

Hey!

A lot of drop-down menus do suck a fair bit on mobile, so tread with caution. If you do need JavaScript how will users without JavaScript use your site? Maybe a drop-down menu isn't the way.

Let's imagine you're set on having a dropdown menu anyway!

I don't know a way how to do it without JS either (that's not to say there isn't a way) so in your case I'd write a little Javascript.

Just to be clear, a lot of people are misinterpreting me (or miscommunication on my part) in saying never use javascript. Feel free to use it, if it's really needed and think about the consequences of it.

Overall my main objection is to large amounts of javascript ruining perfectly good content for lots of users when it wasn't really needed in the first place.

 

You can do dropdowns with CSS transformations. Wish I had a good example, but the app I'm doing now is behind a login.

Sounds like an excellent idea for a post here :)

I'm thinking about it, but I'm not yet convinced I wouldn't just be repeating something posted elsewhere. Looking around though, it looks like I combined approaches that I found in other posts, so it might be worthwhile.

 

The HTML Select Element is all that is needed. No JS required.

 

I really enjoyed this article. I've also been frustrated with the state of the web recently and this article does a good job of putting some of the reasons I stopped using Bootstrap on my personal website into words.

Frameworks have their uses but they are way over used now.

 

I pretty much agree with everything you wrote here.

Probably it's because we have both started building web sites around the same period.

However I think the JavaScript issue is more complex and requires a more radical approach.

Thanks to JavaScript, the Web is a precision weapon.

 

I see the point you are getting at and I do agree with most of it. I haven't fully jumped on the "make everything single page!!!!" train just yet mostly because for the longest time we were just fine without it. For years we didn't need it, how come we just now need it?

You don't need a single page app to have your amazing cook book site. All you need is a database and a way to get the data from the database. A front end framework has nothing to do with that.

I do think JavaScript and full web application have their place, but can we please quit making your blog an entire web application. Most of the time it makes me navigate away. Your blog should be focusing on what a blog is about, CONTENT

 

I get mocked a lot for doing all my webmastering in 99% pure HTML5/CSS.

But it works. Well.

And it looks good by most standards, Rabid Were-designers aside. I focus on delivering information in a logical manner, not hijacking the freakin' scroll-functionality to make giant pictures zip by in 3D.

For example, see my company's website, which I built..

Viva la performance.

 

"but web components are broken"
"But web components aren't ready"
"But web components are slow"
"But nobody uses web components"

groups.google.com/forum/m/#!msg/mo...

Seriously, just use web components.

Here's a slide-based presentation I built, it's just HTML, with behavior handled by web components.

bennypowers.github.io/ecmascript-u...

 

Thanks, Im meaning to look into web components (and vue for that matter)

Some people seem to think that I believe JS (react et al) are evil and all, but it's not the case. I've developed web applications using them.

The point I am trying to make is that most of the time you dont need it and you'll have an easier time developing a progressively enhanced website; and your users will have a better time too.

 

100%.
The head dev at ING expressed this nicely a few years back.

m.youtube.com/watch?v=8ZTFEhPBJEE#

To loosely paraphrase: it's not bad to write JS, but is bad to write (or use) JS that you don't have to.

 

I sought to solve this very problem with my not-a-framework, CSS-based SPA library hafcaf (github.com/andrew565/hafcaf). It's in need of a better readme (in progress), but the gist is you can have your cake (fast and responsive) and eat it too (only as much JS as you want, no more than you need). </shameless-plug>

 

Front end frameworks like React and Vue are just tools. As any good craftsman does, we pick the right tool for the job. If you have a simple blog site that you rarely update then yes, using a framework is probably overkill. There's more to the decision to use a framework or library than page load time, though. How easy is it going to be to add any majorly interactive elements without the use of a library? How about maintaining it several years later? Abstracting a lot of that stuff to a framework helps to add structure and makes maintenance, testing and adding new features much easier. Should you always use a framework? Absolutely not. Is there a need for them? Absolutely there is, you just have to know the benefits and when to use them, as opposed to just going for whatever shiny new thing is in fashion.

 

As any good craftsman does, we pick the right tool for the job.

Indeed and I would contend that a lot of people are picking the flavour of the month tool for the job most of the time

How easy is it going to be to add any majorly interactive elements without the use of a library? How about maintaining it several years later?

What exactly is it about frameworks that make them any easier to update later down the line? If anything i've seen teams spend weeks struggling to update the magnitude of dependencies etc when upgrading versions for their dumb CRUD website that never needed all of that stuff in the first place.

Abstracting a lot of that stuff to a framework helps to add structure and makes maintenance, testing and adding new features much easier

What do frameworks abstract that needs abstracting?

In respect to testing, if they are so good how come so many frameworks require their own specialised testing libraries in order to test them - which is yet another thing on the pile of things to learn and maintain.

 

Images that are lying

This is actually a lie, Philippines is considered to be the slowest ISP in SEA REGION. Please fix this.(😂)

 

As far as simple content blogs go, I really like Paul Graham's blog. Simple html with a bit of CSS and no other crap.

 

It's a bit dated now in terms of approach.

Rather than CSS it is using spacer gifs and things :)

 

aah.. didnt know that.. I simply assumed it was plain HTML/CSS given the simplicity and responsiveness.

 

Yeah, now they develop for SELLING things, internet bandwitdth is one of those.

 

That's a bit paranoid... but maybe you're right.

 

Javascript has tried to fix the web but ended up ruining it.

 

Best post I've seen in a long time

 

A cynical view: HTML+CSS won't pull a software engineer paycheck in most places.

(Read this and skimmed the comments after seeing it linked in another post.)

 

It's a sad world we live in - thanks for pointing it out...

 
 

yay, Argentina here, slow connections for sure (but free, from gov).

 
 

hmm, only 549KB and 88 requests. great!

chromedevtoolsforthisarticle

 

You can always view it here quii.co.uk/The_Web_I_Want but you wont be able to comment, tag... or much else really :)

Also my website has an uhhh unique look and feel

 

And it is a good example that one does not need all that bloat to have a nice and user friendly blog.

 

Hey Chris - this is great! Reminds me of the post I wrote where I called everyone stupid and lazy for using web frameworks.

Only you didn't call everyone stupid and lazy and so people aren't coming at you with pitchforks and torches. Well, not everyone anyway.

(Also every time I read your title I sing it to the tune of "You're The One That I Want" from Grease.)