7 ms·

This seems to suggest the rate of framework churn has rather settled down. Are JS devs finally starting to be satisfied with their current tools and not needing

This seems to suggest the rate of framework churn has rather settled down. Are JS devs finally starting to be satisfied with their current tools and not needing to restart every 18 months?

Touche 10y ago
I don't think the churn has really settled down, what makes you think that? The idea that framework lifespan only lasts 6 months was always exaggerated.
ng12 10y ago
I see this same, tired old meme in every thread about web technologies. It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago. Just because Java systems development hasn't changed significantly in the last 5 years doesn't mean Java devs are any more or less reasonable developers than web folks.
- SeanDav 10y ago
  > "... the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things." It also follows that at some point, these smart, inventive people will come up with fairly stable frameworks that are sufficiently flexible and powerful to accommodate most of the problem space out there. It is reasonable to ask if such a point has been reached...
  - tracker1 10y ago
    Depends on the space.. for example, Express has been pretty stable.. Angular 1.x has been as stable as anything else for the most part... Node's mostly been progressive additions, and features from engine updates since 0.10... npm has been pretty stable since node 0.10, though there's been significant advancements since npm 3 came out. Browserify -> Webpack has been noisy. Babel 5 -> 6 equally noisy, but better for moving forward Today, I think webpack, babel, react, redux and fetch cover a LOT of ground for client-side dev. There's a few other bits around that, and I think CSS tooling is starting the a similar shakeup to node's tooling options. In the end, almost all the JS features I care about seem to be at stage-3 now, so who knows when they'll be in the major browsers.
  - fail2fail2ban 10y ago
    JavaScript has been around since the 90's; a quick scan of this page reveals around 2 dozen JavaScript technologies. The only solution is to remove JavaScript from all browsers and replace it with Java.
    - davidjnelson 10y ago
      Try GWT ;-)
- irrational 10y ago
  I agree that a lot of the churn is each generation (a generation here seeming to be about a year) of tools learning from and building upon the former. Obviously the churn is continuing since developers realize that the tools are quite "there" yet. My hope is that some year we will finally reach "there" (not perfection, but highly good enough) and the churn will slow down to the point that perhaps the generation time period will stretch out to five years or so.
  - tracker1 10y ago
    Well, most of the features I care about in JS are in stage 3 now. Webpack 2 will get the tree shaking, and babel seems ready to work with both. It think the CSS options are next in line to see some shakeup... I've been liking what I'm seeing from JSS, though I still use mostly sass at work.
- majormajor 10y ago
  > The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago. The better question is: are the apps someone with two or three fewer years of experience than you more modular, etc? My experience is on the backend rather than the frontend, but in that domain, at least, system quality is still way more about developer maturity than ecosystem maturity. You can figure out a terrible, hard-to-maintain lazy way of solving today's immediate problems in any language.
  - ng12 10y ago
    I think the problem was the hard-to-maintain lazy way was usually the most obvious. There was so much momentum behind the quick-and-dirty imperative DOM approach that it was hard to do anything else. For example, you could totally use Backbone to construct modular, refactorable views -- but in practice everything would devolve into DOM-munging event-driven spaghetti.
    - z3t4 10y ago
      I think one reason why React is so popular is that it forced you into an object oriented approach whereas before many developers used innerHTML everywhere. It is possible to write object oriented, structured "class" based vanilla JavaScript with imperative DOM manipulations though, witch is more performant then popular frameworks.
      - davidjnelson 10y ago
        Right, it's interesting react had a goal of eliminating xss vulnerabilities so common with the innerhtml approach.
      - shados 10y ago
        "I think one reason why React is so popular is that it forced you into an object oriented approach" And yet React's claim to fame is that it popularized techniques other than OOP, which was plaguing the JS world up until recently.
- mountaineer22 10y ago
  What is your current recommended or dream stack?
  - ng12 10y ago
    Currently my go-to is: React, Redux, Typescript, CSS Modules (optionally with Less) built/managed via npm and Webpack. The real beauty is that everything is well-encapsulated. If I decide one component absolutely needs to use jQuery for some reason there's nothing stopping me as long as the top-level API is still React.
    - davidjnelson 10y ago
      Nice! Why ts over flow?
      - ng12 10y ago
        Momentum, mostly. DT/typings/@types are surprisingly comprehensive and with 2.0 typescript supports strict null checks which was the biggest flaw in my opinion. I've also unfortunately become pretty familiar with some of the obtuse concepts in typescript (e.g. extending module definitions). I'd love to give Flow a try -- just waiting for the right opportunity.
        davidjnelson 10y ago
        Awesome, glad to hear they are doing such great work. Thanks for sharing your valuable insight!
- aquiles 10y ago
  modular, composable, testable, and maintainable apps are great. but what's also great is having a healthy life where you don't spend every waking second trying to learn all the new cool tech. what's the point in inventing better ways to do the same old thing if you're just going to be another stereotypical fat developer with poor posture
- fail2fail2ban 10y ago
  > Web application development is hard Replace JavaScript with Java in all browsers and make it much easier, dependable, predictable and reliable.
  - ng12 10y ago
    Well yeah, that'd be great. But the unfortunate reality is Javascript is the lingua franca of the web and we have to make due until there's a reasonable alternative. Furthmore, it's not even JS that's really the problem. It's the entire JS/DOM/CSS stack.
    - fail2fail2ban 10y ago
      I like the DOM, basic CSS is fine. The twisted stuff some people do with CSS I'm not fine with but yeah I know. JS isn't going away, what irks me the most is the naivety around trying to push it to the backend. It doesn't belong in the backend when the frontend story is so messed up.
      - bschwindHN 10y ago
        Backend JS is not perfect by any stretch of the imagination, but if you limit yourself to plain data and functions and write simple code, it can really work nicely for getting stuff done and iterating on an idea.
nine_k 10y ago
Some forms of "churn" are also called "progress". Is the current crop somehow better than the previous?
lhnz 10y ago
It's not so much that churn has been greatly reduced, but that the worst churn has started to be centralised and hidden behind tools like `create-react-app`. There will still be more churn as people come up with ways to be more productive, however it will be hopefully concentrated in areas other than build process tooling.
- Touche 10y ago
  You're spinning this as a positive thing, but the fact that a UI library needs its own build tool does not speak well to the state of front-end development. Specifically the fact that we still don't have modules or widely-deployed http2 is what makes the build tool complexity necessary.
  - lhnz 10y ago
    I wouldn't say that was spin, I said that build complexity is likely going to be handled by fewer engineers. The underlying problem still exists but less people need to put their oar in: that's bittersweet.
    - Touche 10y ago
      You're pointing to create-react-app as a solution to JS churn when it was just created 2 and a half months ago. The fact that people keep thinking that a 2 and a half month old project is the solution to all of their web development problems is exactly why there's so much churn. Every new tool overtakes the previous generation by being superficially more simple, only to add complexity of its own over time until the next generation repeats the cycle. It turns out the complexity is there whether you acknowledge it or not, and over time your leaky abstractions will burst.
      - lhnz 10y ago
        I don't think that will happen with create-react-app since its intention is zero customisation. You can't generate more complexity with a tool that reduces opportunity for developer choice. A basic example is that a starter app would normally require you to connect 10s of libraries together just to get started. It is difficult to argue that not having to do so is actually more complex.

This seems to suggest the rate of framework churn has rather settled down. Are JS devs finally starting to be satisfied with their current tools and not needing to restart every 18 months?

Touche 10y ago

I don't think the churn has really settled down, what makes you think that? The idea that framework lifespan only lasts 6 months was always exaggerated.

ng12 10y ago

I see this same, tired old meme in every thread about web technologies. It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago. Just because Java systems development hasn't changed significantly in the last 5 years doesn't mean Java devs are any more or less reasonable developers than web folks.

SeanDav 10y ago
> "... the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things." It also follows that at some point, these smart, inventive people will come up with fairly stable frameworks that are sufficiently flexible and powerful to accommodate most of the problem space out there. It is reasonable to ask if such a point has been reached...
- tracker1 10y ago
  Depends on the space.. for example, Express has been pretty stable.. Angular 1.x has been as stable as anything else for the most part... Node's mostly been progressive additions, and features from engine updates since 0.10... npm has been pretty stable since node 0.10, though there's been significant advancements since npm 3 came out. Browserify -> Webpack has been noisy. Babel 5 -> 6 equally noisy, but better for moving forward Today, I think webpack, babel, react, redux and fetch cover a LOT of ground for client-side dev. There's a few other bits around that, and I think CSS tooling is starting the a similar shakeup to node's tooling options. In the end, almost all the JS features I care about seem to be at stage-3 now, so who knows when they'll be in the major browsers.
- fail2fail2ban 10y ago
  JavaScript has been around since the 90's; a quick scan of this page reveals around 2 dozen JavaScript technologies. The only solution is to remove JavaScript from all browsers and replace it with Java.
  - davidjnelson 10y ago
    Try GWT ;-)
irrational 10y ago
I agree that a lot of the churn is each generation (a generation here seeming to be about a year) of tools learning from and building upon the former. Obviously the churn is continuing since developers realize that the tools are quite "there" yet. My hope is that some year we will finally reach "there" (not perfection, but highly good enough) and the churn will slow down to the point that perhaps the generation time period will stretch out to five years or so.
- tracker1 10y ago
  Well, most of the features I care about in JS are in stage 3 now. Webpack 2 will get the tree shaking, and babel seems ready to work with both. It think the CSS options are next in line to see some shakeup... I've been liking what I'm seeing from JSS, though I still use mostly sass at work.
majormajor 10y ago
> The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago. The better question is: are the apps someone with two or three fewer years of experience than you more modular, etc? My experience is on the backend rather than the frontend, but in that domain, at least, system quality is still way more about developer maturity than ecosystem maturity. You can figure out a terrible, hard-to-maintain lazy way of solving today's immediate problems in any language.
- ng12 10y ago
  I think the problem was the hard-to-maintain lazy way was usually the most obvious. There was so much momentum behind the quick-and-dirty imperative DOM approach that it was hard to do anything else. For example, you could totally use Backbone to construct modular, refactorable views -- but in practice everything would devolve into DOM-munging event-driven spaghetti.
  - z3t4 10y ago
    I think one reason why React is so popular is that it forced you into an object oriented approach whereas before many developers used innerHTML everywhere. It is possible to write object oriented, structured "class" based vanilla JavaScript with imperative DOM manipulations though, witch is more performant then popular frameworks.
    - davidjnelson 10y ago
      Right, it's interesting react had a goal of eliminating xss vulnerabilities so common with the innerhtml approach.
    - shados 10y ago
      "I think one reason why React is so popular is that it forced you into an object oriented approach" And yet React's claim to fame is that it popularized techniques other than OOP, which was plaguing the JS world up until recently.
mountaineer22 10y ago
What is your current recommended or dream stack?
- ng12 10y ago
  Currently my go-to is: React, Redux, Typescript, CSS Modules (optionally with Less) built/managed via npm and Webpack. The real beauty is that everything is well-encapsulated. If I decide one component absolutely needs to use jQuery for some reason there's nothing stopping me as long as the top-level API is still React.
  - davidjnelson 10y ago
    Nice! Why ts over flow?
    - ng12 10y ago
      Momentum, mostly. DT/typings/@types are surprisingly comprehensive and with 2.0 typescript supports strict null checks which was the biggest flaw in my opinion. I've also unfortunately become pretty familiar with some of the obtuse concepts in typescript (e.g. extending module definitions). I'd love to give Flow a try -- just waiting for the right opportunity.
      - davidjnelson 10y ago
        Awesome, glad to hear they are doing such great work. Thanks for sharing your valuable insight!
aquiles 10y ago
modular, composable, testable, and maintainable apps are great. but what's also great is having a healthy life where you don't spend every waking second trying to learn all the new cool tech. what's the point in inventing better ways to do the same old thing if you're just going to be another stereotypical fat developer with poor posture
fail2fail2ban 10y ago
> Web application development is hard Replace JavaScript with Java in all browsers and make it much easier, dependable, predictable and reliable.
- ng12 10y ago
  Well yeah, that'd be great. But the unfortunate reality is Javascript is the lingua franca of the web and we have to make due until there's a reasonable alternative. Furthmore, it's not even JS that's really the problem. It's the entire JS/DOM/CSS stack.
  - fail2fail2ban 10y ago
    I like the DOM, basic CSS is fine. The twisted stuff some people do with CSS I'm not fine with but yeah I know. JS isn't going away, what irks me the most is the naivety around trying to push it to the backend. It doesn't belong in the backend when the frontend story is so messed up.
    - bschwindHN 10y ago
      Backend JS is not perfect by any stretch of the imagination, but if you limit yourself to plain data and functions and write simple code, it can really work nicely for getting stuff done and iterating on an idea.

nine_k 10y ago

Some forms of "churn" are also called "progress". Is the current crop somehow better than the previous?

lhnz 10y ago

It's not so much that churn has been greatly reduced, but that the worst churn has started to be centralised and hidden behind tools like `create-react-app`. There will still be more churn as people come up with ways to be more productive, however it will be hopefully concentrated in areas other than build process tooling.

Touche 10y ago
You're spinning this as a positive thing, but the fact that a UI library needs its own build tool does not speak well to the state of front-end development. Specifically the fact that we still don't have modules or widely-deployed http2 is what makes the build tool complexity necessary.
- lhnz 10y ago
  I wouldn't say that was spin, I said that build complexity is likely going to be handled by fewer engineers. The underlying problem still exists but less people need to put their oar in: that's bittersweet.
  - Touche 10y ago
    You're pointing to create-react-app as a solution to JS churn when it was just created 2 and a half months ago. The fact that people keep thinking that a 2 and a half month old project is the solution to all of their web development problems is exactly why there's so much churn. Every new tool overtakes the previous generation by being superficially more simple, only to add complexity of its own over time until the next generation repeats the cycle. It turns out the complexity is there whether you acknowledge it or not, and over time your leaky abstractions will burst.
    - lhnz 10y ago
      I don't think that will happen with create-react-app since its intention is zero customisation. You can't generate more complexity with a tool that reduces opportunity for developer choice. A basic example is that a starter app would normally require you to connect 10s of libraries together just to get started. It is difficult to argue that not having to do so is actually more complex.