4 ms·

This is interesting but good lord, I want nothing to do with any of this. How are you supposed to get anything done if you have to spend so much time just rampi

This is interesting but good lord, I want nothing to do with any of this. How are you supposed to get anything done if you have to spend so much time just ramping up on whatever the new hotness happens to be?

phpnode 11y ago
You don't have to. The tools which worked 10 years ago still work today. The tools which worked 5 years ago still work today. No one forces you to switch to the new hotness, people choose to.
- marklgr 11y ago
  This is not just about tools still working; it's also about maintenance, evolutions, bugfixes, libraries, available workforce etc. If you happen to use an unpopular tool, then you can't easily leverage other people's work and it's harder to find qualified engineers to work for you.
  - noir_lord 11y ago
    Exactly, which is why I'm still using Knockout, it's been around for a long time (for a javascript library), values backwards compatbility and is still developed (only a few developers but they are all committed). It's also just got a lot faster (3.4 had huge speedups) supports HTML5 components and supports IE back to 7 (while that's not a requirement for me it's nice to know the tools you have will work if you need them to). There are features in newer libraries I like but taken in balance I like been able to grab the code I wrote 2 years ago and have it still work with knockout's latest version, to me that is it's killer feature. Also there is this http://knockoutjs.com/spec/runner.html http://knockoutjs.com/spec/runner.html
madeofpalk 11y ago
I don't really understand this. The height of confusion was at the beginning of the article when the author's friend regretted using RequireJS > We talked again last night, and he said that he’d chosen RequireJS. By now, his company had built a massive codebase around it –- “I guess we bet on the wrong horse there.” What makes RequireJS the wrong horse? Is it not doing what it was originally doing? Do you need more from it? How do you build 'a massive codebase' around a module spec? I'm guessing here the person thinks Webpack is the right horse - Webpack supports the AMD spec RequireJS uses if they felt the need to switch (which I can't see why you would), which would minimise whatever changes needed if you had the urge to 'churn'. I think people need to stop getting so anxious about doing what all the 'cool kids' are doing.
- zeemonkee3 11y ago
  I've recently been looking at job boards, and "React" turns up a lot. As does Angular, but not as much as a year or two ago. So it's not so much about whether a given tech works for your project or not (being honest, server-side rendering + dash of jQuery is probably more than adequate for a lot of sites going full-on React+Redux right now) but fear of your skills becoming obsolete. Given the shit-show hiring is right now with its resume filtering and whiteboard hazing (witness every other week on HN) that's not an unfounded fear. So in order to have something on our resume that we used React in our last job, we use React for our current project...and so contribute to the problem.
  - madeofpalk 11y ago
    If you see a lot of jobs requiring React, or are fear becoming obsolete, then just learn React. It's very very simple - the API is like 5 functions, and the documentation takes like 20 minutes to read from start-to-end. Don't learn anything else - just learn plain vanilla-React. The site has a onepager.html 'blueprint' to work from. If people are getting anxious about this, its more than likely self-inflicted from trying to learn 30 things at once that you don't need.
    - zeemonkee3 11y ago
      It's not just React, there's a huge ecosystem developing around it that is undergoing constant churn - see react-router or babel for example. And then with Redux you have a whole subsystem around that - redux-form and sagas and react-redux-router (or is it react-router-redux?). Then we have the GraphQL/Relay train leaving the station. Oh, and I've not even touched testing tools yet, or webpack (a whole other ecosystem on its own). Or CSS modules or... But let's say I did learn all that (in fact, I did recently for a personal side project). It doesn't matter a bit for applying for a job. Why? Because I don't have real work experience using these things. So in order to have that, I have to somehow leverage React into my current job so it can go into my resume.
      - nfriedly 11y ago
jalfresi 11y ago
I still cant for the life of me determine just what it is some of these developers are doing that means the DOM is too slow... I've always approached it as "if the DOM is too slow, I must be trying to do far too much. Scale it back and re-think the problem"

phpnode 11y ago

You don't have to. The tools which worked 10 years ago still work today. The tools which worked 5 years ago still work today. No one forces you to switch to the new hotness, people choose to.

marklgr 11y ago
This is not just about tools still working; it's also about maintenance, evolutions, bugfixes, libraries, available workforce etc. If you happen to use an unpopular tool, then you can't easily leverage other people's work and it's harder to find qualified engineers to work for you.
- noir_lord 11y ago
  Exactly, which is why I'm still using Knockout, it's been around for a long time (for a javascript library), values backwards compatbility and is still developed (only a few developers but they are all committed). It's also just got a lot faster (3.4 had huge speedups) supports HTML5 components and supports IE back to 7 (while that's not a requirement for me it's nice to know the tools you have will work if you need them to). There are features in newer libraries I like but taken in balance I like been able to grab the code I wrote 2 years ago and have it still work with knockout's latest version, to me that is it's killer feature. Also there is this http://knockoutjs.com/spec/runner.html http://knockoutjs.com/spec/runner.html

madeofpalk 11y ago

I don't really understand this. The height of confusion was at the beginning of the article when the author's friend regretted using RequireJS > We talked again last night, and he said that he’d chosen RequireJS. By now, his company had built a massive codebase around it –- “I guess we bet on the wrong horse there.” What makes RequireJS the wrong horse? Is it not doing what it was originally doing? Do you need more from it? How do you build 'a massive codebase' around a module spec? I'm guessing here the person thinks Webpack is the right horse - Webpack supports the AMD spec RequireJS uses if they felt the need to switch (which I can't see why you would), which would minimise whatever changes needed if you had the urge to 'churn'. I think people need to stop getting so anxious about doing what all the 'cool kids' are doing.

zeemonkee3 11y ago
I've recently been looking at job boards, and "React" turns up a lot. As does Angular, but not as much as a year or two ago. So it's not so much about whether a given tech works for your project or not (being honest, server-side rendering + dash of jQuery is probably more than adequate for a lot of sites going full-on React+Redux right now) but fear of your skills becoming obsolete. Given the shit-show hiring is right now with its resume filtering and whiteboard hazing (witness every other week on HN) that's not an unfounded fear. So in order to have something on our resume that we used React in our last job, we use React for our current project...and so contribute to the problem.
- madeofpalk 11y ago
  If you see a lot of jobs requiring React, or are fear becoming obsolete, then just learn React. It's very very simple - the API is like 5 functions, and the documentation takes like 20 minutes to read from start-to-end. Don't learn anything else - just learn plain vanilla-React. The site has a onepager.html 'blueprint' to work from. If people are getting anxious about this, its more than likely self-inflicted from trying to learn 30 things at once that you don't need.
  - zeemonkee3 11y ago
    It's not just React, there's a huge ecosystem developing around it that is undergoing constant churn - see react-router or babel for example. And then with Redux you have a whole subsystem around that - redux-form and sagas and react-redux-router (or is it react-router-redux?). Then we have the GraphQL/Relay train leaving the station. Oh, and I've not even touched testing tools yet, or webpack (a whole other ecosystem on its own). Or CSS modules or... But let's say I did learn all that (in fact, I did recently for a personal side project). It doesn't matter a bit for applying for a job. Why? Because I don't have real work experience using these things. So in order to have that, I have to somehow leverage React into my current job so it can go into my resume.
    - nfriedly 11y ago

jalfresi 11y ago

I still cant for the life of me determine just what it is some of these developers are doing that means the DOM is too slow... I've always approached it as "if the DOM is too slow, I must be trying to do far too much. Scale it back and re-think the problem"