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!
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.
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.
JSX (at least in React) is not perfect though, but I'll come back to that.
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.
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.
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.
div here and slap on 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
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.
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.)
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 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!
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.
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.
If you know that framework, tell me! I want it!
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...