5 ms·

That's good, in each cycle, sooner or later you get improvement: webpack over grunt, react over jQuery and npm over vendoring your jQuery plugins. OP forgot ho

That's good, in each cycle, sooner or later you get improvement: webpack over grunt, react over jQuery and npm over vendoring your jQuery plugins. OP forgot how life looked when your web app project was handcrafted HTML page with manually inserted scripts tags. When your form submission was multi-level backend API in PHP. jQuery plugins with 20+ options published randomly on the internet.

aaronbrethorst 8y ago
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.
colinmegill 8y ago
Strongly agree. What was a larger team is now a part time project. That's a goal and outcome of the churn.
LoSboccacc 8y ago
there's still lot of churn coming from following a moving target. like when ios made the top of the page untouchable least it pulled safari out of full screen, breaking the toolbar convention of the past two decades. and when ios made the bottom of the page untouchable least it pulled safari out of fullscreen, breaking the bottom bar icon webapp did under the very apple guidelines > https://developer.apple.com/ios/human-interface-guidelines/bars/tab-bars/ https://developer.apple.com/ios/human-interface-guidelines/b... and when ios made the app sides unusable due to a varying notch, having a whole set of unstandard properties you have to handle to manage correctly being into safari on a iphone x if we had companies following standard decently and a linear, planned grow instead of the organic mess we're into, it'd be far easier to produce building blocks that work in a stable manner over time. we're better today than in netscape days, but marginally. as complexity increase the cost of this constant churn does too and the saving from better framework are not quite enough to offset the constant fads that come and go.

aaronbrethorst 8y ago

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.

colinmegill 8y ago

Strongly agree. What was a larger team is now a part time project. That's a goal and outcome of the churn.

LoSboccacc 8y ago

there's still lot of churn coming from following a moving target. like when ios made the top of the page untouchable least it pulled safari out of full screen, breaking the toolbar convention of the past two decades. and when ios made the bottom of the page untouchable least it pulled safari out of fullscreen, breaking the bottom bar icon webapp did under the very apple guidelines > https://developer.apple.com/ios/human-interface-guidelines/bars/tab-bars/ https://developer.apple.com/ios/human-interface-guidelines/b... and when ios made the app sides unusable due to a varying notch, having a whole set of unstandard properties you have to handle to manage correctly being into safari on a iphone x if we had companies following standard decently and a linear, planned grow instead of the organic mess we're into, it'd be far easier to produce building blocks that work in a stable manner over time. we're better today than in netscape days, but marginally. as complexity increase the cost of this constant churn does too and the saving from better framework are not quite enough to offset the constant fads that come and go.