4 ms·

The phrase using a shotgun to swat flies comes to mind. These modern frameworks and tool chains solve very well understood problems. They enable large teams of

The phrase using a shotgun to swat flies comes to mind. These modern frameworks and tool chains solve very well understood problems. They enable large teams of software engineers to collaborate and release complicated interrelated software on predictable schedules. Not every project has this requirement. For smaller projects the overhead and the included complexity that comes as a result of using these frameworks and tool chains vastly overshadows the benefits.

HereBeBeasties 7y ago
The hidden benefit is that when your small project becomes medium sized, you won't need to rewrite it all from scratch...
s_y_n_t_a_x 7y ago
You should develop every project like it's an enterprise level app. Why would you rewrite it in a different tech when it's ready to grow? It's easier to use, why shoot yourself in the foot. It's a myth you need a large team to create a React app.
- dclusin 7y ago
  https://arxiv.org/pdf/1702.01715.pdf https://arxiv.org/pdf/1702.01715.pdf From the bottom of page 11: Most software at Google gets rewritten every few years... (continues with another paragraph). In most of the companies Ive worked at for more than a few years some major piece of the architecture changes in ways unforeseen by the original designers. This usually incurs massive changes on the frontend, since it's often the glue that wires everything together. Migrating to react from a simpler framework is a minuscule amount of the effort. Large structural changes for growing software products are the norm, not the exception. If your project never gets past the initial stages its pointless to plan for the future when there might be none. Which is what this guy's project was, an initial project on a weekend retreat.
  - s_y_n_t_a_x 7y ago
    The skeleton I use to create weekend projects is the same as what I use to create enterprise projects. I don't see the need to juggle "simpler" frameworks for no reason, especially when those "simpler" frameworks are harder to use (because you have to remake everything yourself) There are many small things I don't want to recreate that are always needed in every web app. Translations, authorization, accessibility, bug tracking, and more. Another person said it best. You aren't going to use your own C++ compiler just because it's simpler and you don't need all the features, why do the same to the toolchains for the web?
    - dclusin 7y ago
      Following this logic Spring never would have been invented in the Java world because Java EE does everything you need it to even though you don't need all of those features. Frameworks and tool chains become bloated and convoluted over time. I'm not super well versed in react/js/etc web development, but given the regularity that you see and hear about these sorts of posts, a not insignificant minority feels like the toolchain is overly complex for lots of use cases. If it wasn't then the post wouldn't have made it to the front page. It wouldn't have been upvoted just like our comments in this discussion :) Just because you find the toolchain an easy to understand time saver that's pretty DRY doesn't mean everyone else does. Who knows? Maybe complexity in React will continue to increase and someone somewhere will invent the Spring equivalent for React. Why would they? Because they didn't need all of those features. (Also thought of Vue.js spinoff from AngularJS)

HereBeBeasties 7y ago

The hidden benefit is that when your small project becomes medium sized, you won't need to rewrite it all from scratch...

s_y_n_t_a_x 7y ago

You should develop every project like it's an enterprise level app. Why would you rewrite it in a different tech when it's ready to grow? It's easier to use, why shoot yourself in the foot. It's a myth you need a large team to create a React app.

dclusin 7y ago
https://arxiv.org/pdf/1702.01715.pdf https://arxiv.org/pdf/1702.01715.pdf From the bottom of page 11: Most software at Google gets rewritten every few years... (continues with another paragraph). In most of the companies Ive worked at for more than a few years some major piece of the architecture changes in ways unforeseen by the original designers. This usually incurs massive changes on the frontend, since it's often the glue that wires everything together. Migrating to react from a simpler framework is a minuscule amount of the effort. Large structural changes for growing software products are the norm, not the exception. If your project never gets past the initial stages its pointless to plan for the future when there might be none. Which is what this guy's project was, an initial project on a weekend retreat.
- s_y_n_t_a_x 7y ago
  The skeleton I use to create weekend projects is the same as what I use to create enterprise projects. I don't see the need to juggle "simpler" frameworks for no reason, especially when those "simpler" frameworks are harder to use (because you have to remake everything yourself) There are many small things I don't want to recreate that are always needed in every web app. Translations, authorization, accessibility, bug tracking, and more. Another person said it best. You aren't going to use your own C++ compiler just because it's simpler and you don't need all the features, why do the same to the toolchains for the web?
  - dclusin 7y ago
    Following this logic Spring never would have been invented in the Java world because Java EE does everything you need it to even though you don't need all of those features. Frameworks and tool chains become bloated and convoluted over time. I'm not super well versed in react/js/etc web development, but given the regularity that you see and hear about these sorts of posts, a not insignificant minority feels like the toolchain is overly complex for lots of use cases. If it wasn't then the post wouldn't have made it to the front page. It wouldn't have been upvoted just like our comments in this discussion :) Just because you find the toolchain an easy to understand time saver that's pretty DRY doesn't mean everyone else does. Who knows? Maybe complexity in React will continue to increase and someone somewhere will invent the Spring equivalent for React. Why would they? Because they didn't need all of those features. (Also thought of Vue.js spinoff from AngularJS)