Etsy Moves from React to Preact

It's been a little while since i had to work in the React + TypeScript project (nowadays use Vue more often) so it's not fresh in my memory, but sure!

For starters, even your example shows the awkwardness somewhat, it is essentially the same as writing the following (if you don't need the interface elsewhere):

  const Component: React.FC =
  ({prop1, prop2}) => {
      return ...
  }

Suppose i want to add a new property: now i need to do it in two places (the interface definition, with either syntax). Want to remove one? Same story. Rename one? Sure, your IDE should let you do this, but the change is still necessary in two places. Why couldn't i do something like this instead (the answer is that the language is just not structured that way, but clearly having duplication for no good reason whatsoever isn't nice):

  const Component: React.FC(prop1: string, prop2: number) => {
      return ...
  }
  
  or
  
  const Component: React.FC(props: Props) => {
      return ...
  }

Contrast that with a pure JS implementation (which is bad because it doesn't tell you about the individual props or their types, but surely one can also imagine just a list of different prop parameters):

  function Component(props) {
      return ...
  }

Of course, that's more of a nitpick, but the code often reads worse than Java does in my eyes.

Another thing that i disliked was working with union types, especially when you're stuck with loosely defined objects in a legacy codebase, where you can't always work with properly structured definitions of "this one thing is a union of BASE FIELDS but also ADDITIONAL FIELDS FOR ENTITY TYPE A that won't be defined in separate places, because if we split it up for some reason this one library integration will fail to render UI components properly".

I started writing out more about that particular case, but realized that articulating precisely what was the problem in it and diving back into that older codebase to recreate code examples would take time and sadly i don't really care for doing that. But hey, JavaScript would let you just wing it and check each field individually before trying to access them, so you could let the code decide the behavior, not the type system, which is sometimes the path of least resistance. Personally, i think that strong type systems are always good in the back end, but i feel less strongly in that regard about front ends.

Also, i'm not sure that building TypeScript on top of JavaScript was the best idea: surely from a support/target platform perspective it was brilliant, but sometimes you get all sorts of awkwardness.

For example, the React TypeScript bindings themselves have something like the following:

  type Booleanish = boolean | 'true' | 'false';

Oh, and in regards to TypeScript in particular (though this is also annoying in Angular etc.), their implementation of even enums is awkward. Consider that in Java you can easily turn any string into an enum value if possible and can also have enums act as containers for additional data, for example: https://www.tutorialspoint.com/how-to-convert-a-string-to-an...

I think the biggest problem with this is that Preact is not a 100% drop-in replacement for React. The devil is in the details. The programmers will casually follow online answers from stackoverflow or blog post regarding React and apply them to the Preact project. This will work more often than not, but from time to time you can run strange bugs, which only happens on Preact and it takes much time to detect and debug them.

Heh, this seems like a case of different people having completely opposite experiences.

Had to work on an Angular project or two, they were largely passable and didn't cause too many problems. Admittedly felt a bit close to writing back end code at times, even - pretty boring and predictable. In Angular the type system was also reasonably easy to use, even with things like non-nullable/nullable/optional values etc.

Had to work on a few React projects, the JavaScript ones were pleasant to work with and develop (seriously, React's functional components are an amazing time saver for display components), but as soon as you introduced TypeScript and Redux as well as plenty of hooks and even custom hooks, it went down the drain.

Perhaps that's a bit what you're experiencing with RxJS, which adds a ton of complexity in of itself - being able to start with just Angular and go from there (or in my case - using MobX instead of Redux which is just so much nicer to use) might have been more passable.

Actually made a sibling comment like this, though it's not as detailed as i'd like: https://news.ycombinator.com/item?id=30220131

But hey, good luck with bending Angular to your will! If nothing else, i can acknowledge many codebases out there being a mess!

Doesn't explain why they could not have continued using React 15.

I've definitely run into this in my own past as well. On one hand, you can understand the business incentives - ship something relatively quickly, have it look good enough to attract attention or at least not scare anyone away.

For example, compare the front pages of SourceHut (a lovely and lightweight project) https://sourcehut.org/ and GitLab (a really good self-hostable solution with plenty of features) https://about.gitlab.com/

One of those would capture the attention of most people better, so that's what the market will optimize for at large, unfortunately also sometimes pushing focusing on other things with less visibility (to the average user) to the back.

For the simpler things, not asking for permission can be a good idea (depending on the environment and circumstances) - a line that i heard in a software development conference once was: "You don't ask your manager for permission to write tests for your code, so why should you for making other similar decisions that are essentially just doing your job well?"

Of course, then you also become responsible for the potential impact of those changes and things going wrong, so it works better on simpler cases/optimizations and only as long as the things you're changing are simple enough to have almost no impactful bugs or you have enough tests in place to catch any.

Other times you can succeed by adopting a data driven approach and a healthy helping of taking initiative: "Hey, our automated performance tests indicate a regression in page load times of X% after version Y, which, according to these random but serious looking studies and posts might result in lost potential conversions and could cost us Z$ the following year. I've described these problems and what to do in Jira issue #W and have escalated the priority to 2, so that's what i plan on doing this week. Any questions?"