11 ms·

The requirements for the kind of things described here often come from above us in the form of creative comps, feature requirements, timeline constraints with r

by vesrah 9y ago

The requirements for the kind of things described here often come from above us in the form of creative comps, feature requirements, timeline constraints with respect to required functionality, etc. This is something that should probably have been touched on in this article. I do completely agree with the sentiment, so I guess this is just me projecting frustration :)

fhood 9y ago
I think a lot of people agree with the sentiment. Most of the points here are ones that have been hashed and rehashed countless times in various blog posts and whatnot. People just tend to write code first, and only worry about optimization if it becomes an explicit issue.
smoe 9y ago
I'm not sure if the requirement from above is true most of the time. A lot of developers nowadays default to using a SPA as the starting point for everything without even considering if they actually need the whole bouquet of fronted build pipeline, innumerable dependencies, reactive something and a dozen layers of abstractions to hardly do more than loading and turning JSON into html while showing a spinning thing. Sure, there are plenty of features of frontend frameworks that come in handy. But how often do devs truly analyze what the best tool for the job is vs. chasing after that shiny newthing.js which just came out.
- CM30 9y ago
  I don't think it's just about novelty here (though as said, chasing the new shiny thing seems to play a large role none the less), but also because: 1. Developers want their CV/resume to look good for the next job, and the best way to do that is to have a bunch of fancy technologies and frameworks on it. Going for what's simple and works best is great, but unfortunately not something recruiters (especially at large tech companies) care much about. 2. They're used to that one language or framework, and hence think every single problem under the sun should be solved with it. It's the old 'when all you have is a hammer' issue, and endemic in every company from the small agency to the large tech corporation.

by vesrah 9y ago

fhood 9y ago

I think a lot of people agree with the sentiment. Most of the points here are ones that have been hashed and rehashed countless times in various blog posts and whatnot. People just tend to write code first, and only worry about optimization if it becomes an explicit issue.

smoe 9y ago

I'm not sure if the requirement from above is true most of the time. A lot of developers nowadays default to using a SPA as the starting point for everything without even considering if they actually need the whole bouquet of fronted build pipeline, innumerable dependencies, reactive something and a dozen layers of abstractions to hardly do more than loading and turning JSON into html while showing a spinning thing. Sure, there are plenty of features of frontend frameworks that come in handy. But how often do devs truly analyze what the best tool for the job is vs. chasing after that shiny newthing.js which just came out.

CM30 9y ago
I don't think it's just about novelty here (though as said, chasing the new shiny thing seems to play a large role none the less), but also because: 1. Developers want their CV/resume to look good for the next job, and the best way to do that is to have a bunch of fancy technologies and frameworks on it. Going for what's simple and works best is great, but unfortunately not something recruiters (especially at large tech companies) care much about. 2. They're used to that one language or framework, and hence think every single problem under the sun should be solved with it. It's the old 'when all you have is a hammer' issue, and endemic in every company from the small agency to the large tech corporation.