Questioning Modern Web Development
Photo by Markus Spiske on Unsplash.
Then what about developers who are wanting to explore concepts or programming paradigms? Object orientated vs functional? Imperative vs declarative?
All of these factors resulted in millions of developers picking up the language and making it the popular girl at the dance.
For example, Google wants to build their web applications one way. Facebook wants to build their web applications another way. Google creates Angular. Facebook creates React. Both frameworks achieve the same thing. Both frameworks use the same language. Both frameworks have a legion of developers who have sworn allegiance. Both do some things better or worse than the other. Then Vue comes along and claims to be more progressive than it's competitors and, thusly, the market continues to grow with more options.
Not only does every framework have it's own design and architectural patterns but libraries and concepts are now being coupled with that framework. Angular developers are most likely not going to understand the Flux architecture that Redux follows and React developers aren't going to understand Angular's approach to resolvers. Each framework is going deeper and deeper down it's own path and as time passes, the similarities between them begin to thin.
I don't know what the answer is. Maybe it's a completely open source (not owned by a FAANG company) framework? Maybe it's a framework that allows you to write code either in an object-orientated or a functional fashion? Maybe it's time we just give in and leave the title of "Frontend Developer" behind and take the helm of "React Developer", directly coupling our career and livelihood to the survival of something that is completely outside of our control.
How do we go about bundle splitting?
Time to get a little bit more technical.
As any application grows, so does it's bundle. If you're unfamiliar with how SPA (single paged applications) work, your browser downloads the whole application the first time you visit the website. This is an issue because if a user is only accessing the FAQ of your site, they've still had to download every other page that your site has to offer.
Bundle splitting helps solve this by breaking your code into multiple bundles that can be lazy loaded. In this way, only your FAQ page would be downloaded to the user's browser until the user requests a different page. First problem solved.
The next problem is that you're going to make changes and update your web application. This means that the bundle has changed and potentially the index file that was tracking the lazy loading of your modules has also been changed. This means that users with an outdated bundle will be viewing an outdated version of your website.
In my opinion, the best solution is to create a system that alerts the user that their version of the site is out of date. react-hook-form does this quite nicely by presenting the user with an alert, informing them to update to the latest version.
Even if this process is done tastefully, it's still a very off-putting experience to the average user and is something we need to figure out a better approach to.
Is Server-Side Rendering worth it?
SSR also introduces you to another problem: how are you going to go about authenticating your user? You're going to have to forward your cookies, tokens etc to the API for authorization/authentication. This means you could never cache the result either because what the server is going to render is dependent on the user's permissions. On top of this, you need to make a request to the server every time the user requests a new page.
SSR will solve some of your problems but it can introduce you to just as many.
Why must APIs be so infuriating?
APIs are there to bring the frontend to life. Give us the data we need so that we can show it to the world. Such a pure concept but the execution is nothing short of the Red Wedding from Game of Thrones.
For example, a REST API that follows the practice of not coupling too many things is going to result in the frontend having to make multiple requests just to display one page. Get me my permissions but also get me a list of users. Oh, also get me my profile data. Duh.
This is an incredibly annoying and tedious process, yet, I understand and accept it. We can't put all that data into one endpoint because then we're crossing concerns and mixing data objects together on our backend. I understand this and so I make multiple API calls to cater for the backend's philosophies. But what if my frontend philosophy is to not have to make 3 API calls before I'm allowed to even render anything to the user? Will the backend surrender to my frontend's will?
There is a disjoint between backend/APIs and frontend applications. Each have constructed their own way of doing things, best practices and so on. This is done without the other in mind. A backend without a frontend makes for a nearly impossible user experience that would only allow for users who have a good understanding of HTTP requests to be able to make use of the system. A frontend without a backend is just as pointless as a static website without any content.
Where will the web be 10 years from now?
I'm not even going to pretend to know the answer to this but I'll give it a go. The enhancements of sites like Wix scare me because potential client could have everything that they need right there, in a nice drag-and-drop UI. Potential clients that want to make use of my deep React knowledge could eventually replace me with something like GPT-3 if it gets to the point that it could seamlessly integrate, build and improve upon your code.
This post may seem pessimistic or negative, but that's not the case. I simply believe that we need to challenge and question everything. Questioning one of the most important inventions in human history and how we continue to build that invention is probably one of the greatest questions we can ask ourselves as web developers.