4 ms·

I feel like this is a false dichotomy. The choice doesn't have to be roasting squirrels over an open flame/handcrafting PHP pages vs. shiny futurism/Node+React.

I feel like this is a false dichotomy. The choice doesn't have to be roasting squirrels over an open flame/handcrafting PHP pages vs. shiny futurism/Node+React. I have been getting along just fine with Rails, HTML, and a sprinkling of JS for over 10 years.

ehnto 8y ago
There is an immense productivity gain to be found in mastering a set of tools. After a while of dogmatic tooling changes you begin to analyze more critically whether the new shiny thing is going to provide any real value. I would argue that for the huge majority of websites, tried and tested tooling is perfectly fine and definitely more robust and supported. Every tool you introduce is hours of troubleshooting just waiting to happen.
emodendroket 8y ago
That stuff works fine if your client-side needs are simple, but if you actually want a single-page application, or just an application with a lot of rich JS functionality, it quickly becomes unwieldy.
- Chris_Newton 8y ago
  That stuff works fine if your client-side needs are simple To be fair, just about anything works fine if your client-side needs are simple. However, I have reached the opposite conclusion to you: the more customised and complicated and large-scale and long-lived the software becomes, the less value I see in a lot of the popular but ever-changing web technologies and the more I am likely to favour building on the standard foundations with minimal dependencies in between and usually a relatively small but high-value set of libraries. The benefits of quickly fetching many tiny packages with a package manager or of building on top of all-encompassing frameworks or automation tools are mostly found in two situations, in my experience: getting started quickly (including rapid prototyping exercises) and ongoing development if (and only if) you are staying almost entirely within the bounds of what your chosen technologies already do well. However, if your requirements start to evolve and diversify in a longer-lasting project, it’s all too easy for those numerous tiny dependencies to become a liability or for that framework or tool you built everything around to become a straitjacket. The relatively short lifetimes of many of these technologies can also become an expensive problem if the community drifts away and the security and compatibility work slows down or stops entirely but your project still depends on them as much as ever.
  - emodendroket 8y ago
    I don't like microlibraries very much either, but that's a different question. A monolithic frontend framework can make your life easier.
    - jhall1468 8y ago
      Monolithic frameworks can also corner you into edge cases where you end up having to write shitty work arounds because their "opinionated" framework didn't have an opinion based in reality.
      - emodendroket 8y ago
        Yes, and a car can go off the road and kill you. Nevertheless I don't choose to walk everywhere I go.
        jhall1468 8y ago
        That was my point, that nothing solves every problem. Monolithic frameworks aren't inherently better than micro libraries, they are just different paths to achieving the same goal. I'm still going to choose micro libraries, because flexibility is more valuable to me than batteries included, which is just as good an argument as batteries included is better than flexibility.
        emodendroket 8y ago
        Fair enough. Still, "I don't like microlibraries" is not an argument against client-side frameworks.

ehnto 8y ago

There is an immense productivity gain to be found in mastering a set of tools. After a while of dogmatic tooling changes you begin to analyze more critically whether the new shiny thing is going to provide any real value. I would argue that for the huge majority of websites, tried and tested tooling is perfectly fine and definitely more robust and supported. Every tool you introduce is hours of troubleshooting just waiting to happen.

emodendroket 8y ago

That stuff works fine if your client-side needs are simple, but if you actually want a single-page application, or just an application with a lot of rich JS functionality, it quickly becomes unwieldy.

Chris_Newton 8y ago
That stuff works fine if your client-side needs are simple To be fair, just about anything works fine if your client-side needs are simple. However, I have reached the opposite conclusion to you: the more customised and complicated and large-scale and long-lived the software becomes, the less value I see in a lot of the popular but ever-changing web technologies and the more I am likely to favour building on the standard foundations with minimal dependencies in between and usually a relatively small but high-value set of libraries. The benefits of quickly fetching many tiny packages with a package manager or of building on top of all-encompassing frameworks or automation tools are mostly found in two situations, in my experience: getting started quickly (including rapid prototyping exercises) and ongoing development if (and only if) you are staying almost entirely within the bounds of what your chosen technologies already do well. However, if your requirements start to evolve and diversify in a longer-lasting project, it’s all too easy for those numerous tiny dependencies to become a liability or for that framework or tool you built everything around to become a straitjacket. The relatively short lifetimes of many of these technologies can also become an expensive problem if the community drifts away and the security and compatibility work slows down or stops entirely but your project still depends on them as much as ever.
- emodendroket 8y ago
  I don't like microlibraries very much either, but that's a different question. A monolithic frontend framework can make your life easier.
  - jhall1468 8y ago
    Monolithic frameworks can also corner you into edge cases where you end up having to write shitty work arounds because their "opinionated" framework didn't have an opinion based in reality.
    - emodendroket 8y ago
      Yes, and a car can go off the road and kill you. Nevertheless I don't choose to walk everywhere I go.
      - jhall1468 8y ago
        That was my point, that nothing solves every problem. Monolithic frameworks aren't inherently better than micro libraries, they are just different paths to achieving the same goal. I'm still going to choose micro libraries, because flexibility is more valuable to me than batteries included, which is just as good an argument as batteries included is better than flexibility.
        emodendroket 8y ago
        Fair enough. Still, "I don't like microlibraries" is not an argument against client-side frameworks.