Rewriting vanilla JS to Typescript isn't that big of a deal though. It would be more like building a house on a budget, then adding some fancy paint, furniture and alarm system.

In my experience, if you spend a few weeks in the "exploratory" phase writing ES6, rewriting to TS won't take more than one or two days.

Nowadays I'm a lot better at Typescript and will use it from the get go, but for someone who is less skilled in it, it might much faster to produce working code first and add types later.

Alternatively, you can write in Typescript from the get go with most of the strict checks disabled, then only enable a certain check when you see the need.

I see so many HN comments endorsing "build the product to exact specification using the minimum reasonable tool set." When you then ask "what happens when the specification changes?" you get hilarious answers like "just say no to the user", or "just extend the app!"

This is why I always over engineer a bit, especially on new projects. I'll happily, for instance, add a framework before it's strictly necessary. I've never regretted that decision in the end.

If people here want to use a 5 gallon bucket on an initial 5 gallon job, go for it. Best of luck to you. I'll be over here starting with a 10 gallon bucket and not sweating when the customer needs to add another gallon...

One of the things that I've learnt is that the world isn't clear-cut enough for YAGNI[1] all the time, and that it's usually worth building things slightly more generic/flexible than the original ask, because it's rare that the original requestor understood the problem enough first time round.

[1] https://martinfowler.com/bliki/Yagni.html

There are so many automated safe refactore and build time safeguards you can do with statically typed language, I’m much more comfortable making major changes and extension with Typescript than vanilla JS.

The problem with overengineering is that you don’t have a good grasp on a generalized architecture until you have two or three use cases. Of course anything dealing with cross cutting concerns like logging and authentication it’s easier to add up front.

I don’t know any modern front end frameworks, but when working within a team, I’m all for opinionated popular frameworks. It’s s lot easier to onboard people and from a completely selfish standpoint, developers who are concerned with their careers want to be able to put a transferable toolset on their resume.

It’s rare that I find a comment which validates my own practices like this. I personally love creating systems and abstractions, and admittedly I will sometimes create one when a simpler solution would suffice. However those “over-engineered” solutions have frequently saved me lots of time much later when business requirements change.

Your stance sounds different to the grandparent's.

There's a world of difference between adding a framework and over-engineering something that could have used a simpler solution.

My experience has been the exact opposite of yours, whenever I added something complicated, it either never got used and unnecessarily complicated the code, or when the time came to use the fandangled cleverness I lovingly wrought, it never quite met the need I actually ended up having.

So I stopped doing that years ago and now always write the simplest code. Never regretted it. I will add frameworks early though.

That is an excellent approach for new projects. On stable projects it's pretty common to have lots of little "special" bits where someone over-designed and created an unholy mess. (I'm guilty of this as well, of course.) In stable systems simple is almost always best.

I think it depends on what you're engineering. For example, adding static typing to a language has immediate gains regardless of code base size. It is also low risk and easy to implement.

Designing a spring quartz scheduler backed by a DB when a simple cron job would do? That's overkill.

There’s a difference between an extra layer of abstraction/indirection and going crazy with the a bunch of new hot (unnecessary/inapplicable) technology.

Now the non-strawman version: it's a 5 gallon job, vanilla React.js is already a 10 gallon bucket, and typescript comes in buckets up to 100 gallons.

It's often a matter of how much you think the job is likely to expand, how much you should frontload work to make that simple.

Saying "Don't do premature optimization" is easy. By saying "premature" you're already implying that you can tell when something is premature. What's hard is when you don't know when something early will come back to bite you later.

I had this problem last year, I ended up just rewriting an entire web application in a couple weeks. It wasn't a big or complicated app, it was only going to be used by a few people, but I had one requirement change that made me redo a lot of work. If I "over engineered" a little bit more it would have totally been fine.

This.

I always focus more on the "foundation" part, in this case, it's common React Hooks and its API for the components to use.

The good part is, if some hooks are wrong, we can just write new one and replace old ones within old components without the need of taking care of the old wrong Hooks.

Aren't Hooks too new for you to make claims about what you "always" do with them?

Before, it was HOC and RenderProps. This is just an example with Hooks, it's mostly how i approach the problem though.

Right on, makes sense.

I couldn't agree more with you on this.

I often see good, actually simple solutions get turned down due to people saying "that's too complicated for what we need", only to later hear, after a couple of months in production, that nobody wants to touch the codebase anymore since it's unapproachable and the rewrite will not happen due to high risk since it's critical production code now.

There must be some bias here in what your remembering. Are the projects that didn't need to be extended, simply doing what they need to, sticking out in your memory

You might be right and maybe there is some bias in the projects which I chose to think of. Certainly there are many projects that don't require the same amount of thought from day one.

What I'm referring to in my previous comment is when people underestimate the complexity added by the easy and quick solution today vs the high cost over time. Specially in critical projects.

> This one never ceases to amaze me. Any codebase is small, until it gets big.

do y'all work on the linux kernel or what ? most of the projects I've seen across multiple jobs are less than 5000 loc. And they never will "get bigger" because they are not "products" that get evolved over time.

I don't know why people make such a big deal of types. They don't add that much time to typing the code.

I also have noticed that if you write daily using some code style (for example using types) it takes time to switch to another style, for example without types. So you are better of using types, because you are used to it and you will code faster that way anyway.

For me, it is less about typing and more about being sidetracked with hard-to-debug Typescript issues.

I also use HOCs a lot and it's painful with Typescript.

Well, in React's case if you use PropTypes, the rewrite is mostly mechanical, and can be automated via things like https://github.com/lyft/react-javascript-to-typescript-trans...

But many tools, flow, Python, TS allow you to incrementally add types to an existing codebase. That way refactoring isn't some herculean effort, but something you can do for new features, or gradually over time.

So many of these "do you really need" articles are this, authors who don't understand the idea of scaling

You don't need to rewrite to add types.

If you want type-safe code you will usually have to rewrite some parts of your app, or most of it if someone butchered the initial implementation.

In theory maybe you are right. In practice it never just adding types. E.g. you need to add null checks, rewrite old parts to follow same style (in case there are old parts in the code) and etc.

This usually happens anyway when you figure out how to do something better. Then need to apply it everywhere else.