5 ms·

> Nobody is forcing you to try new stuff and then talk about js fatigue This is just not true. I recently had a discussion at work where I was flat out asked "

> Nobody is forcing you to try new stuff and then talk about js fatigue This is just not true. I recently had a discussion at work where I was flat out asked "how do you expect to learn new things if you don't try new libraries?". Coming up with a solution yourself (assuming these libraries are even introduced to solve an existing problem, which is sadly not always true) was not seen as an acceptable answer... The options appear to be assimilate into this culture, or find a new industry to call home. Front-end dev doesn't appear to be for people that care more about a lean, pragmatic stack than a trendy one.

aaron-lebo 9y ago
Coming up with your own solution when it isn't informed by other solutions just means you are building another poor alternative. Frankly these frameworks and libraries are all very similar and they do very similar things. Once you've learned one you can transition to the others quickly (it's the same way with old web frameworks, MVC frameworks are all the same with minor tweaks). They are worth evaluating though because some of them do one thing better than others, might as well borrow it where possible. I love learning new technology because even if I don't end up using framework x or y, I can pick up the best parts and use it in my own work which becomes simpler and more expressive as a result. I don't want to keep building websites from 2005. There have been some real advances and it's fun touse the best parts.
- BigJono 9y ago
  Yes, you're building a poor alternative. But you learn far more than you ever would just by using the existing libraries, by virtue of learning what not to do. Using other's tools is trading off knowledge for development time. It's often a good trade to make, but to pretend that learning the API surface of library #34341 is going to improve your skills more is wrong.
  - amackera 9y ago
    Nobody said learning API surfaces is the right way. Most of these frameworks offer fairly simple APIs that are frankly pretty trivial to learn --- the key is to learn the application architecture and why it's different than the alternatives. Anyway, I think we can agree that exposure to other people's thoughts, and also coming up with your own thoughts, is probably the most fruitful way to learn.
degenerate 9y ago
Your work buddies have it wrong. You don't need to "try" new technology, you simply need to "learn" it. When something new pops up, see what people on HN are praising/hating. Hop on StackOverflow and see what the noobiest questions are for a taste of the installation and compatibility issues. Read some of the questions with multiple replies but no accepted answer to see how toxic or hepful the community around it is. If the new tech has an official forum/chat, hop in there and browse around for a bit. You'll pick up pretty quickly if a new stack, DB, or framework is worth using or not... you don't even need to touch it. Scientists publish papers so other scientists don't have to run the same experiments over and over. We have HN, SO, and other developer communities for that purpose. Read, learn, watch, wait. "Try" at the point you think it sounds so perfect, you have to try it.
- bsaul 9y ago
  Your comment makes me realise there should be a way to categorize technologies solely based on stackoverflow post metadata analysis (number of questions, number of answers, answer scores repartitions, time between question and answers, etc..)
  - johnny22 9y ago
    also average activity on github. Get a feel for how issues and PRs are handled. Sentiment analysis on issues/PRs would be nice there too.
unclebucknasty 9y ago
What you're touching on is a change in dev in general, especially in certain parts of the stack (like much of front-end). That is, devs have become more assemblers than coders. I think this is due to the explosion in OSS, with all of the libs, frameworks, etc. On balance, I believe it's made us more productive, but the time spent writing logic has gone down vs. the time spent learning, assembling, integrating, etc. So, devs are expected to keep up on all of the latest tech, tooling, etc. Of course, the demands of agile development just pours gasoline on it.

aaron-lebo 9y ago

Coming up with your own solution when it isn't informed by other solutions just means you are building another poor alternative. Frankly these frameworks and libraries are all very similar and they do very similar things. Once you've learned one you can transition to the others quickly (it's the same way with old web frameworks, MVC frameworks are all the same with minor tweaks). They are worth evaluating though because some of them do one thing better than others, might as well borrow it where possible. I love learning new technology because even if I don't end up using framework x or y, I can pick up the best parts and use it in my own work which becomes simpler and more expressive as a result. I don't want to keep building websites from 2005. There have been some real advances and it's fun touse the best parts.

BigJono 9y ago
Yes, you're building a poor alternative. But you learn far more than you ever would just by using the existing libraries, by virtue of learning what not to do. Using other's tools is trading off knowledge for development time. It's often a good trade to make, but to pretend that learning the API surface of library #34341 is going to improve your skills more is wrong.
- amackera 9y ago
  Nobody said learning API surfaces is the right way. Most of these frameworks offer fairly simple APIs that are frankly pretty trivial to learn --- the key is to learn the application architecture and why it's different than the alternatives. Anyway, I think we can agree that exposure to other people's thoughts, and also coming up with your own thoughts, is probably the most fruitful way to learn.

degenerate 9y ago

Your work buddies have it wrong. You don't need to "try" new technology, you simply need to "learn" it. When something new pops up, see what people on HN are praising/hating. Hop on StackOverflow and see what the noobiest questions are for a taste of the installation and compatibility issues. Read some of the questions with multiple replies but no accepted answer to see how toxic or hepful the community around it is. If the new tech has an official forum/chat, hop in there and browse around for a bit. You'll pick up pretty quickly if a new stack, DB, or framework is worth using or not... you don't even need to touch it. Scientists publish papers so other scientists don't have to run the same experiments over and over. We have HN, SO, and other developer communities for that purpose. Read, learn, watch, wait. "Try" at the point you think it sounds so perfect, you have to try it.

bsaul 9y ago
Your comment makes me realise there should be a way to categorize technologies solely based on stackoverflow post metadata analysis (number of questions, number of answers, answer scores repartitions, time between question and answers, etc..)
- johnny22 9y ago
  also average activity on github. Get a feel for how issues and PRs are handled. Sentiment analysis on issues/PRs would be nice there too.

unclebucknasty 9y ago

What you're touching on is a change in dev in general, especially in certain parts of the stack (like much of front-end). That is, devs have become more assemblers than coders. I think this is due to the explosion in OSS, with all of the libs, frameworks, etc. On balance, I believe it's made us more productive, but the time spent writing logic has gone down vs. the time spent learning, assembling, integrating, etc. So, devs are expected to keep up on all of the latest tech, tooling, etc. Of course, the demands of agile development just pours gasoline on it.