I programmed my first website back in 2016 using PHP. After shortly playing around with Angular.js I started doing React. I'm now doing it as a full-time job for two-and-a-half years. This is my retrospect on web-development, my current pain points, and about my view on the role of React in it.
There will be four categories, lent from a basic retro format:
- Keep: What do I want to continue doing
- Less: What do I want to do less
- More: What do I want to do more
- Add: What do I want to add that is not yet there
With that out of the way, let's get started!
Keep
Component based web development
Using components has been an eye opener for me. Looking back at my first PHP website, I had to write a lot of markup multiple times. Copy-paste at its best. I did not have something in place (or the knowledge to start doing it) that let me reuse parts of my markup.
React excels at this. The whole library is designed around components. And I think it's one of the main reasons why it became so successful.
JSX
This is one of the most controversial parts around React. I really like it though. And for me it's a big reason why it's hard to move from React to some other frameworks like Angular, Vue or Svelte.
For all those frameworks I have to learn and use a certain templating language, and those will always be restricted in some kind of way. JSX is also something that you have to learn, but afterwards it's just JavaScript. You can embed arbitrary expressions, the full power of JavaScript at your fingertips.
JSX (at least in React) is not perfect though, but I'll come back to that.
Less
Configuration
It's a pain to set up something new. The amount of configuration is overwhelming. Webpack, TypeScript, jest, continuous integration, automated deployment, and especially making different tools work with each other.
It's getting better already. With Next.js and Vercel you can build some pretty sophisticated web applications without writing a line of configuration.
JavaScript
You could also say "code" in general. The amount of bytes we send out to our users is often hilarious. We tend to forget that not everybody is browsing our web applications from localhost with blazing fast internet connection using the latest MacBook Pro. We don't feel the pain of users with less powerful devices that try to use a "modern" web full of JavaScript every day.
I know that there are many solutions to reduce the time that users have to wait for your page to load. Code splitting ensures that you load the most important JavaScript first. Server-side-rendering already presents the user with markup in the initial HTML. But - at least in the React world - you still need to load the same amount of JavaScript overall. (I don't have enough knowledge about other frameworks to make an equivalently qualified argument.)
One solution for everything
This point continues where the last one left off. React is evolving into a "one size fits all"-solution for web applications. Many websites have very little need - or even none at all - for dynamic page content. A ton of blogs, wikis and doc-sites out there are 100% static and would not need React at all. (I'm not alone with that opinion.) Just using HTML and maybe a little vanilla JavaScript where necessary would do.
Tools built on top of React - most notably Gatsby and Next.js - call themself "static site generators". I find this quite ironic, because they in fact do not create truly static sites. They create server-side-rendered React applications. You still get all the JavaScript that you would get from a client-side-only React application. (Well, unless you work around their core ideas by e.g. using plugins that force Gatsby to leave out the JavaScript parts.) However, at least Remix - the new kid on the block - shows some more love here and won't include any JavaScript on your page if you don't actually need it.
The ecosystem and the variety of tools around React grew so much that we started using React as a bazooka to kill the fly. We don't think about choosing the adequate tools for the job anymore.
More
HTML
HTML provides a rich set of elements full of semantic meanings and built-in functionalities. But as a novice developer starting to learn React, you don't notice any of it. For sure it was the case in my journey.
Use a div here and slap on a span there. Thanks to CSS and JavaScript, basically every website could be built just using elements without any semantic meaning. But there's a good reason why there exists a button element or a form element. Ever pressed enter to submit a login form and nothing happened? Looks like the developer had no idea how to implement a basic HTML form.
HTML - and in fact also CSS - are the basis on which the web is built. We have to stop head-starting to use React without ever having built a webpage using plain HTML and CSS.
Let's also talk about JSX again real quick. To me, the biggest flaw of JSX in React is that it's a mix of HTML (the elements) and DOM-IDL-names (the attributes). I guess everyone scratched their head at least once about writing className instead of class. The same goes for event handler attributes, here you need to write onClick instead of onclick.
I'd like to see a JSX implementation that is closer to HTML. In my opinion this is more intuitive and understandable and would avoid a lot of confusion.
Server-first
If client-side-frameworks were the hit of the 2010s, then server-side-frameworks are the hot thing in the twenties. It's not that great to start out with an empty HTML file and thus a white screen in your browser while having to wait until at least the minimal amount of JavaScript is downloaded, parsed and executed. By doing so we skip the part on which the web is built: HTML!
While Next.js is a great framework for server-side-rendered React applications, it's built on React. And React is a library primarily designed for client-side applications. It was not designed with a server-first mindset. (Thus the need for frameworks like Next.js in the first place, that abstract away the pain of using the server-rendering APIs and creating a server that spits out the pre-rendered HTML.)
When looking at the success of Next.js and Gatsby, I think it's important to design our frameworks, libraries and web applications with a server-first approach and using client-side JavaScript as a second step to make the UX as smooth as possible.
TypeScript
Oh my, how TypeScript changed my developer life! From the point when I started using it, I felt so much more confident in the code that I wrote.
I won't lie, I spent hours chasing TypeScript errors and trying to figure out what I did wrong. I believe the fact that a lot of libraries and frameworks are built using just JavaScript plays a factor here. If you want TypeScript you need to use external type definitions that are outside the scope of the actual package. For smaller libraries there might not even be existing type definitions. Thus, typings are often imperfect and TypeScript is not able to infer all necessary variable types, resulting in a loss of confidence in the code.
I bet on TypeScript becoming more widely adopted in the coming years. And I like it. If tools are built with a TypeScript-first-approach, the confidence you get in your code and the improved developer experience is totally worth it!
Opinionated frameworks
That's more a personal note. I like being restricted as a developer by the tools that I'm using. Restricted in a sense of how I do certain things, not what I want to do.
I don't want to adjust to the way imports and exports are handled, how the files are structured, how components are named or how tests are written, each time I switch from one codebase to another. Those things should be pre-defined, and every developer should adjust to them. It would drastically reduce friction and improve our industry's efficiency overall.
Add
What is there left to add? I mentioned choosing the right tool for the given job. But what if there isn't one?
If I want to build a highly dynamic web application I'll gladly continue choosing React for it. If I need to scale the website, use server-side-rendering for optimal SEO or use static-site-generation to even skip the SSR for pages where I don't need it, Next.js has me covered.
But what about small and simple websites? Like my personal blog page, the website of my local sports-club or that restaurant next door that just wants to widen their audience by being present online.
I have not yet found any framework that brings together the (subjectively) best of all world: Something using Components and JSX (or something else that's just JavaScript), built completely in TypeScript, that gives me minimal and zero-JavaScript static files while also providing basic and simple APIs for client side DOM manipulation.
If you know that framework, tell me! I want it!
Conclusion
After almost three years doing React, I have the feeling I've seen everything. (Well, except for that release of Suspense.) When starting something new, I seek for something simpler. After all, the best code is no code. Also, the best client-side JavaScript is no JavaScript at all.
As for the framework I mentioned above, there's only one option left in "build-vs-buy" if the latter is not available. So I built it. (Well, let's say I'm in the middle of building it.)
But more on that at a later time...
Top comments (3)
Definitely Svelte! It's super-fast, easy, simple to learn, and just awesome overall! It's just the framework you're looking for! If you're interested, I've written up a guide about it which you can check out here. thejavascriptninja.com/svelte-tuto...
I tried Svelte, and it's indeed a cool framework. It also inspired me to try to hack together my own solution. But there are a couple of reasons why it doesn't match my wishlist:
It's been quite some time though since I had a closer look at Svelte. In particular I did not work with the latest major version 3 yet. So some of the things mentioned above could be outdated :D
It looks like you didn't tried Svelte.