10 ms·

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once

by chmln 8y ago

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.

revskill 8y ago
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.
- chrisweekly 8y ago
  Aren't Hooks too new for you to make claims about what you "always" do with them?
  - revskill 8y ago
    Before, it was HOC and RenderProps. This is just an example with Hooks, it's mostly how i approach the problem though.
    - chrisweekly 8y ago
      Right on, makes sense.
a_wild_dandan 8y ago
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...
- scarface74 8y ago
  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.
- gav 8y ago
  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 https://martinfowler.com/bliki/Yagni.html
- justintoon 8y ago
  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.
  - mattmanser 8y ago
    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.
bengale 8y ago
You don't need to rewrite to add types.
- daliusd 8y ago
  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.
  - mixmastamyk 8y ago
    This usually happens anyway when you figure out how to do something better. Then need to apply it everywhere else.
- pault 8y ago
  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.
amzans 8y ago
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.
- tayo42 8y ago
  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
  - amzans 8y ago
    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.
wrestlerman 8y ago
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.
- arvinsim 8y ago
  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.
ht85 8y ago
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.
- true_religion 8y ago
  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.
jcelerier 8y ago
> 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.
threatofrain 8y ago
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.
- AtHeartEngineer 8y ago
  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.
bytematic 8y ago
So many of these "do you really need" articles are this, authors who don't understand the idea of scaling
geewee 8y ago
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-transform 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.

by chmln 8y ago

revskill 8y ago

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.

chrisweekly 8y ago
Aren't Hooks too new for you to make claims about what you "always" do with them?
- revskill 8y ago
  Before, it was HOC and RenderProps. This is just an example with Hooks, it's mostly how i approach the problem though.
  - chrisweekly 8y ago
    Right on, makes sense.

a_wild_dandan 8y ago

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...

scarface74 8y ago
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.
gav 8y ago
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 https://martinfowler.com/bliki/Yagni.html
justintoon 8y ago
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.
- mattmanser 8y ago
  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.

bengale 8y ago

You don't need to rewrite to add types.

daliusd 8y ago
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.
- mixmastamyk 8y ago
  This usually happens anyway when you figure out how to do something better. Then need to apply it everywhere else.
pault 8y ago
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.

amzans 8y ago

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.

tayo42 8y ago
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
- amzans 8y ago
  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.

wrestlerman 8y ago

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.

arvinsim 8y ago
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.

ht85 8y ago

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.

true_religion 8y ago
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.

jcelerier 8y ago

> 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.

threatofrain 8y ago

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.

AtHeartEngineer 8y ago
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.

bytematic 8y ago

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

geewee 8y ago

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-transform 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.