Developers' choices and where do I stand

Project boilerplate generators

Solutions like create-react-app, create-react-native-app, or Expo.

These are amazing tools for learning the technology, creating a quick prototype, or testing a new library on a fresh setup. Utilities like these save a lot of time when you need to get the primary task done fast, and don't want to spend time configuring build process, ES/TS, tests, etc. I don't mind using these for validation of a proof of concept, or even short lived prototypes of web/mobile apps.

However, there are situations and projects where I would opt for a step-by-step configuration on my own. Typically, for a serious projects, or large applications. The biggest drawback I see in using these generators, is that they hide a lot of complexity from a developer. Which is good for playing around, but on a proper project, you want to be sure what's going on under the hood of a production build. You should be able to adjust or fix any configuration you might need.

What these tools do, is they provide a way to eject the wrapper and expose the configuration in full scope. When this happens, it could be overwhelming amount of config files and settings one has to go through. Especially if this is the first time developer has to deal with webpack config and babel settings.

It happened to me several times in my professional career, when I got to a project that has been developed for months, and running on the boilerplate generated configs. And everytime, the developer experience or build process has been inconvenient, slow, or overcomplicated. The first thing I always did was that I spent few days cleaning the repository by removing create-react-app, removing unnecessary files, service workers settings, server-side rendering, etc. On projects where I could start from scratch and set frontend stack and build support incrementally, the initial ramp up was slower (in hours), but we never had days of slowdown to rewire the stack and optimize something that was already solid. And I'm not even counting the time that developers on the running projects spent waiting for the inefficient build to run, or the page to rerender because of SSR misuse.

React: hooks vs class-based lifecycle

When React hooks were introduced, I stayed away from the hype. For a reason. I wanted to see where it will get to, if it's gonna get time-proven and deliver the promise of better code and practices. I wanted to avoid that hype of "let's rewrite well-working class components to functional ones with hooks". That sounded as a really bad idea to me, and it still does today. Months after their release, I started to dig in and use hooks in my own code.

I must admit there are situations where hooks are priceless, and save a lot of hassle. They help with code reusability and readability (arguable - read on). I'm not adding performance into the mix, as I haven't seen real performace issues caused by frontend for a long time. I grew fond of being able to use functional components with hooks, to get clear and to the point code. For example, being able to just have useToggle for boolean-like properties is really nice. But!

There are still cases where I use class components and their lifecycle. Usually, this has to do with my internal compass of when to use functional and when class based component. This is for another post itself, but in general, I mix both approaches and even rewrite one to another at certain iteration over the code. Usually, class based components work great for any component, that has a bit more logic involved, or where I want to avoid chains of hooks. I've seen terrible use of hooks, where developers would pile tens of hooks in the render method, making it a mess. I don't say there's a specific number of hooks that makes sense, but I think we should be cautious with "overhooking" the components. Seeing too many lines concerned with hooks is a good indication that the component could be poorly designed, in my opinion.

At that moment, I usually look at the commonality among hooks used, and see if I should extract some part of component, or turn it into class based component, to get a different component API, make lifecycle a bit more explicit, or gain better code cohesion.

Backbone.js in 2020

Recently, I've been asked what do I think about Backbone.js in age of react. Since I've been using backbone.js a lot between 2009-2015, I was curious if backbone is up these days. I was pleased to find out it is still around (last release of 1.4.0 in Feb 2019). I felt a bit nostalgic looking at it's site, and remembered all the fun I had using it.

Although I would probably not reach for Backbone, if I could get along with React on larger projects, I would still be happy to give it a go as a library on either backend (for Model/Collection features), on a small projects, or where React is not desirable for some reason (existing project with already bloated stack). I wouldn't mind at all to work on a project that is using Backbone or Marionette.js.

Using Backbone taught me a lot about applications architecture, separation of concerns, browsers' DOM, and a lot about javascript itself. The beautiful thing about it is that the library is easy to dig into, learn about methods' internal mechanisms, and one can override anything, if the need is. Something I cannot say about React and its "magic" workings. Of course, these are both very different realms to compare.

Flutter vs React Native

There's been a lot of hype around Flutter, a new tool for building mobile/web/desktop apps. When I talked to my friends about me getting back to React Native development, many of them suggested to give Flutter a try. I've been pessimistic about it and didn't install it yet. For several reasons.

One, it's a new shiny thing. And I have my reservations about these projects. The fact something is brand new, doesn't mean it's good to go with it. I rather give it some time to warm up and get a community around it. Early adopters who want to spend time trying it out and finetuning it. Which is amazing and honorable. But it's not for me. I want to use tools that are time proven, tested by crowds of developers, and as they say - battle-proven. Which I don't see with Flutter just yet. I remember when I used React Native last time, in 2017, and it was pain to get the app running from day to day. A lot of things were breaking, changing every other day, and the stability just was not there. It cost me a lot of time to actually be developing the app, and not fixing builds and emulators. I don't want to relive this again with Flutter.

Two, it's a different language to learn. Yup, as much as I like learning new stuff and languages, in this case I just wanted to be able to roll out features and not getting stuck with a syntax that is new to me. I didn't have a chance to try Dart, and I want to spend my precious time for fun projects differently.

If I ever get an opportunity to use Dart or Flutter as part of my full time job, or a contract, I'll be more than happy to dive in. However, it will take some more time before I would be willing to give Flutter a chance for my next app idea.