Hey Devs, happy Friday π¦₯π
As always, it's been an eventful week in the tech industry. We've got a lot to talk about! And today I want to discuss...
This post by @oxharris about the state of the sprawling frontend ecosystem π³π
Check out these quotes from the post:
So it turns out, all of that "vibrant ecosystem" isn't really translating to more "accessible", "functional" apps on the user front, and neither to more "speed" and "productivity" on the developer front!
The closer you get to Frontend's bottlenecks and to how much of that is tooling-induced the more you are wondering if we just have created more problems with our tools than we've solved!
So...what do you think? π€
Top comments (11)
I read this back when it was published. Some really good ideas and proposals here - all about using ideas from modern web development but in a more foundational way - without all the bloat. I've been in web development for a long time and I've seen a huge ballooning of tooling that has indeed probably created more problems than it has solved.
I really pity new devs coming to web development today - it's a complex minefield with everyone telling you their way of doing things is the best way, and an attitude towards development that has become increasingly about convenience rather than an actual understanding of the technologies being used... all driven by a social media style 'content' and 'likes' culture.
Hey Jon,
Excited to share a follow up post detailing some of those proposals:
dev.to/oxharris/revisiting-the-htm...
I'm into web development for only 2 years, but my current role already requires me to do the architecture too (not a wise decision to hand this off to a junior though π ). At first I was happy, because I could choose the tools for a greenfield project.
My choice of frontend framework was React. As much as it was easy and exciting in the beginning, it became a source of frustration 1 year later as the project (and the complexity of data it has to handle) grew. Constant battling with weird state update results, too many re-renders, the complexity of useEffect (which now runs at least twice on mount, thanks to react18, introducing even more weird behaviour if you're not careful)...
Of course deadlines were approaching, and I suddenly found myself writing quick and dirty solutions just to be ready on time. I really like JSX, because I don't have to jump back and forth between the template and the business logic, and it's absolutely possible to create readable code with it. But when I was in a hurry... man... if you've seen ugly code! JSX definitely triumphs in that. I didn't thank myself that debug session afterwards. π
Client side rendering has the great benefit reducing the calculations the backend server has to do, but that means a lot more data going over the wire.
I started to think, that this is far from perfect to use in every scenario, the ideal solution should be a hybrid implementation of CSR, SSR, and SSG, that would change somewhat dynamically, taking into account the current workload of the server and the usage metrics to ensure the fastest load times and the least amount of data sent through to the client.
And luckily I'm not the first one thinking along these lines. There are really promising solutions coming our way in the shape of meta-frameworks. NextJS is just the beginning. Take a look at SolidStart and Qwik. They are incredibly fast, scalable in a way that doesn't require sending more data to the client, use React-familiar syntax and taking care of code splitting on their own. And this is where AI could come handy: analyzing the contents of a component tree and choosing the ideal place to collect and analyze how clients interact with the web app, it could easily determine the ideal way of how the app should be bundled.
Hi Attila, you have an intriguing story.
Excited to share a follow up post detailing some of those proposals:
dev.to/oxharris/revisiting-the-htm...
I think web developers should focus on more real problems and problems worth to solve, like those problems users may find painful to deal with, or enabling users to use the app and the web how they would like to.
Some frameworks focus too much on formal problems, like paradigms, ideas, ideologies, the way people may think of and work with apps and web, or the way developers work. They want to take over the fundamentals but they really don't give enough in return.
Some focus on minor issues like reducing 100ms download time but failed the real problems. 100ms is huge for you but it may mean nothing for your users. A piece of junk that runs fast is still junk. But they solve problems anyway, so it is still better than those ideology junks.
So my point is to know what your users really need. Ok they may not need your app at all but that's another story. It don't need to be reactive, or functional as in fp, or pure, or oop if it is still a thing, or follow any paradigms, principles or standards. Ok there is still a standard: it should work, it should work correctly, it should work widely, it should work the way your user would want it to, it should cooperate or at least not harm your users. And, it should be fast enough but it really don't need to be bleeding fast.
Excited to share a follow up post detailing the initial proposals:
dev.to/oxharris/revisiting-the-htm...
Frameworks/ecosystems exchange freedom by imposing conventions which solve problems, until they need to be bent and/or abandoned in favor of a new set of conventions by another framework to solve maybe the same problems + 1. The whole process is manly driven by the path of least resistance (how "easy"/"cheap" it is do use it), so, eventually, money. The end results (the apps) are really just a side effect of all that, that's why their overall quality is not progressing as fast as tools.
Hi Alain,
Excited to share a follow up post detailing the initial proposals:
dev.to/oxharris/revisiting-the-htm...
My view is that react is for web apps, and html just isnβt a good fit for apps. I hope some day we just write for canvas, and spend those thousands of code-hours on working from the ground up, with the raw pixels on the screen, rather then piling hack after hack on top of an obsolete DOM. Apps are not documents! π€
Hi Andrew, I might agree with you 50% in my follow up post detailing some of those challenges and the proposals around each:
dev.to/oxharris/revisiting-the-htm...
I think, you are absolutely right.
But there are good reasons, why the whole community got stuck in a circle, where every solution creates more problems than it solves.
I have always wandered, why some of the principles of software development, that have been crucial to manage large software projects in the past, seem to be simply forgotten in the world of web developers. Or maybe they never knew?
Good old COM-applications written in C++ or Pascal or even a mixture of different languages often contain some 100k of lines of code. An we had ways to manage this complexity.
Ok, the web is a bit more about some fancy "design". On windows, you can select a "theme" to change the appearance of your app. The app just presents some menues to do the user interaction.
So, I think, things are not "that" different, if you create web apps or offline apps. Maybe itΒ΄s worth to see, how things have been solved in the past to learn for the future.