loading...

Webdevs! Are we on the right track?

sayanarijit profile image Arijit Basu Updated on ・4 min read

Webdevs! Are we on the right track?

Has it ever happened to you that you tried to open a site and the browser freezes.
You then tried to restart the browser, it tried to reopen the last active page and crashes again?
It's probably not your fault but (some of) us, the lazy, time and coin saving web developers.

To dig into where the problem lies, let's take a quick dip into the evolution of web.
I will try my best not to bore you (I'm not a big fan of history myself).

  • Initial computers used to be Mainframe. i.e. a big centralized powerhouse of resources with multiple "dumb", non graphical client terminals connected to it. It hosted both processing power and data storage. There was no concept of network. So web was still not born yet.
  • Then came File Sharing computing. "dumb" terminals became "smart" clients with the invention of LAN. The centralized computers only hosted data which the clients used to download, process and upload back to the centralized computer. Similar to what we currently do with cloud hosted documents. With this development, all the processing shifted from the centralized computer to the client machines. So the clients became bulky. It should be noted that by "client", I'm not referring to the general public as Internet was yet to come.
  • The file server architecture caused a lot of resource wastage as clients cannot share unused resources with other computers. Also the network got congested because of all the downloading and uploading going on. So we stepped back and shifted the processing back to the centralized computer (server). However, the clients remained intelligent enough to render the data sent from server in a more understandable format. It required minimal processing on the client side, so the resource wastage reduced. Also, to update some data, clients don't have to download the whole file. So the network congestion was also solved. This is the Client Server Architecture, the backbone of today's internet.
  • In the late 1990's, with the evolution of internet, the client-server architecture evolved into Web Oriented Architecture. The servers processed data received from requests obeying a standard protocol HTTP and sent back response data in the same format. This standardization of request handling protocol allowed the mass public to render the response data in their client machines via an application program called "browser".
  • When more and more public started using the web, the competition between browser programs raised. Browsers cannot stay the "dumb" programs that it used to be anymore. They got a scripting language. The almighty JavaScript. Now the clients can do more than just rendering the response received from a server. It can alter the way browsers render the data. It can interact with the user, do processing on it's own, and request more data from servers on it's own.
  • So, we entered the era when clients receive rendered data, interacts with the user, performs API requests on behalf of the user and re-renders the data. It's the era of AJAX. The majority of processing and rendering was still handled by the servers.

So that was some history on the evolution of web. Let's enter the era where we are now.

It's the era of Progressive Web Applications, caused by the explosion of countless JavaScript frameworks that can render the entire website in a single page. The servers now do some processing and sends the data and the logic to render the entire site to the client browsers, shifting a lot of processing required back to the clients. With this, we, web developers are starting to develop a mindset: "processing is supposed to happen on the client side, let's free up the servers and let the consumers carry the burden". And it's not sufficient yet. We are soon going to adopt WebAssembly. This adoption is going to erase the need of JavaScript to write client-side rendering logic and will allow us to use programming languages of our choice in the browser. It's going to allow us shift more and more processing to the client browsers.

So here is the question. Are we on the right track?

From the history we learned that the whole point of client server architecture was to keep the clients as thin as possible and let the servers take the load. We are developing web apps on a machine with high speed processors, plenty of RAM, and connected to high speed internet (all relatively) and often forget about the real users of our web app. The majority of population is still on the low-end side of processing power and memory with low internet speed. Recall how Facebook make it's employees use 2G every tuesday to feel the pain of it's consumers on slower network? Sadly, most of us, web developers are too lazy to do it.

Instead of focusing on "user friendly"-ness, we have started focusing more and more on "developer friendly"-ness. Who cares about the users, We will just post a banner like:

Oops! Looks like your mobile sucks. Please get a device with 8 core CPU and 16GB RAM to load this page.

The users will take it as their fault.

Discussion

markdown guide
 

Are we on the right track?

Nope, we're not.

Allow me to be blunt. We're overemphasising a narrow strip of the technology stack (single page applications) to the detriment of simpler solutions (HTML/CSS).

Just examine the frontpage of Dev.to - read the post titles. Does this suggest to you that our industry values writing server side solutions and making honest tradeoffs? Or does it suggest that our industry favours a landscape of SPAs built with a series of fragmented frameworks?

Maybe this is driven by ignorance. Maybe this is driven by hype. It's hard to work out the tradeoffs of one approach over the other with an incomplete understanding of one or both. It's hard to use an unfashionable solution when your employer/industry is riding the hype train.

 

I'm afraid that I quite agree with you here. PWAs can be really great for certain use-cases, but this mad rush to convert every "dumb" webpage into a PWA definitely feels like the wrong choice. It's actually quite annoying to land on a casual blog when browsing on my phone and be asked to install it to my phone. Why in the world would I want to install a blog offline?

IMO, "dumb" HTML/CSS with little-to-no Javascript is a highly underrated technology choice. It's fast and light on resources, doesn't suffer any of the "jank" that PWAs tend to have when landing on the page, the process of building them is significantly simpler, and viewing the raw page source actually gives me useful content.

 

And I was the one that championed adding 'Should users be allowed to disable Javascript' in the 'State of DEV' survey. Even so, one of the projects I'm most proud of is the one that's usable entirely with Javascript completely disabled.

I do think the feedback loops have also hurt this issue. If you remember a couple years finding a PHP host was easier than finding good websites. But then the industry said 'php bad'. And so we moved to SPAs as a result and the server moved to (php/laravel) and other langs like Go, Python, and more. But no where to host them. Hosting an SPA is easy. netlify.com/ is the most seamless dev->prod DXP I've ever seen. But it only works if your app is an SPA. Because then all the host has to do is set up DNS and a file server.

There's a huge gap in places than are able to host more hobby server apps that have hobby pricing.

 

You are on the right track however you missed one huge topic that drives a lot of decisions surrounding the client server relationship: cybersecurity. One of the other reasons to use Web Assembly other than developer ergonomics is that it runs in a sandbox.

You touched on throttling which is important.

When developers make a product more client heavy it’s most likely not by choice, but necessity or lack of backend expertise.

One problem that SPA causes is that webpages are no longer statically analyzable by web crawlers, in other words they are not search engine optimized. Server-side rendering of SPA solves this issue and shifts some of the heavy lifting rendering DOM back to the server but now it’s more dynamic rather than static.

 

When developers make a product more client heavy it’s most likely not by choice, but necessity or lack of backend expertise.

Or maybe they're just enjoying the ride on the SPA hype train and can't think outside of that box.

 

I'd say we're definitely on the right track, I've been in the industry for quite some time now and it's amazing to see how far things have come... but, it's entirely up to us as developers to ensure we cater to our user demographics and pick the technologies we use accordingly. If the majority of your users are on 2G using low-end devices, then your app needs to be lightweight with minimal processes that could block the main thread. On the other hand, if your users are on high-end devices with high speed connections then it could be an ideal situation to push some boundaries.

 

I don't agree with the concept of categorizing websites by the device or network "majority of users" use. I think web is supposed to be open for everyone. If we have to enable more features, we have the option to build dedicated desktop/mobile clients instead of emulating those on the web.
If we have no option but do provide all the features on the website, we should at least provide a "load HTML only" option for users that use low end device or are in slow network even if the numbers are less.

Also, if we provide no option for low-end device users to open our site, "majority" of our users will always be high-end device users. Unfortunate people won't even complain. They will just blame it on their device or fate and leave forever.

 

I agree that progressive enhancement is the way to go, but I also understand that in business it's often majority rules. Yes, this will alienate some potential users, however from a business standpoint you're going to allocate your resources towards where the demand is. If the company has a lot of resources, then I imagine they would allocate them towards developing on multiple platforms, but if they don't then they'll put their efforts towards the majority. I agree, in an ideal situation you cater for all - it just doesn't always work out that way and that's when it's up to us as the developers to pick the technologies we use to best cater for the majority.

 

Interestingly, you could have made the same point in computer graphics in the 80ies/90ies. But was anybody forced to stay VGA? Only to show how crappy user experience under VGA is? No.

This is a double edged sword or more abstract: It is a multi facetted problem:

  • There may be the lazy developer, but that cliche is too easy to exploit
  • There may be some kind of economic pressure in form of deadlines

But there are also:

  • Increased demands on the side of customers or (end-)users. Yes my Nokia 3210 had incredible battery lifetime. But the best you could do with it was to play snake. Nobody wants that again, do we?

  • More powerful devices which would otherwise be idling all the time

  • Better networks for more and more people

The question

So here is the question. Are we on the right track?

is misleading. Say we - as developer - come to the conclusion, that we - indeed - are on the wrong track, what would be the right track? Only display textual information?

Instead of focusing on "user friendly"-ness, we have started focusing more and more on "developer friendly"-ness.

If you take into account what I said above, this is plain wrong.
It starts with the wrong assumption of a hypothetical "we", which is only true for some cases.

 

Yes I used "we" wrongly. I mentioned "(some of)" or "majority of us" in few places but couldn't mention like this everywhere I wrote "we".
You are right that we have to move forward with technology like we moved from VGA. But people who can't afford today's high-end graphics still has the option to buy a VGA phone and play snake. But web is a single platform. If we move forward on this track, WWW may become something only for people who can afford to buy such high-end device. And since hardware and software companies are always on competition, they will have no objection rolling out more and more expensive devices every quarter. I am using a somewhat modern smartphone (although a budget one and 2 years old), yet it crashes on so many sites. I don't think this was WWW all about.

There are developers and companies that focus a lot on user experience and try to cover as much users as possible regardless of what device they use. But my concern is that it's not followed by everyone who builds websites that strictly. The modern frameworks and evolving technologies also do not focus on this area that strictly. We have been given the freedom to use unlimited processing in client-side. There's no limit or warning popup on this from the framework.

It's up-to us, developers to test what we build on common devices, but we are not required to. Hence, most often we (objective) don't. And this made me doubt the track we are on.

 

If we move forward on this track, WWW may become something only for people who can afford to buy such high-end device.

The implicit question is another: When businesses lay their focus on users of high end devices, wouldn't that exclude users? To that question, the answer is definitively: yes.

But that is not a problem of using fat clients and rich user experience - because there is already an audience for that. The solution would be to deliver your site in several versions depending on the target device. I see no problem having a powerful device and a good connection seeing the resources used.

It is a problem of business adressing those people and broaden the expierence overall.

yet it crashes on so many sites. I don't think this was WWW all about

This is a subjective problem, which I can not say anything but the useless counter statement: I have no such problems.

But at least, you are right: the web was not about crashing sites.

But my concern is that it's not followed by everyone who builds websites that strictly

I tend to agree. But I see this as a responsibility of said companies.

There's no limit or warning popup on this from the framework.
I do not understand: Why should it?

Hence, most often we (objective) don't. And this made me doubt the track we are on.

As I said above, the question you are raising is not:
Are we on the wrong track.
No I think we aren't!

But more of: Should we offer multiple tracks to ride upon.
Yes, I think so.

The solution would be to deliver your site in several versions depending on the target device.

This is exactly what we need. Modern tech and frameworks should really consider improving in this area. If the low-end device users has a option to load a fully functional (and practical) website, no matter how ugly it is, then it would be the time to add bloats as optional features for high-end users.

Wikipedia is a good example of a practical site that's for everyone. Gmail is another example of a great site because it provides the flexibility to "load basic HTML". So it's also for everyone.

 

Great Article!
I feel exactly like you, and the main reason is that I was taught apps must be tested in the worst case (hardware and software). As the older computers used to have limited processing resources, most developers had to think into ways to improve apps performance. However, as you said, many developers don't have the same awareness, and, as a result a bunch of bloated apps have been released nowadays. MAYBE it is a result of a series of factors such as Agile wrongly used, trendy technologies and also companies that on and on are more worried about profit instead of quality!

 

I think it went wrong when everybody started using technology, which purpose was describing and linking documents, for applications.

It went even wronger when folks started to adapt tech from huge companies, which purpose was solving the previous point, for their small/medium sized apps.

Just to clarify points from the article and the comments, WebAssembly is not there to replace JS/DOM/etc. and it will run in the same sandbox as JS, so no improved cybersec. there.

 

I believe the main word in TRADEOFF.

It's all about tradeoffs of different approaches.