3 ms·

All of your points are good ones, but just to clarify: 1) While there are already new approaches to CSS via Webpack and CSS modules which in a way completely i

by cnp 11y ago

All of your points are good ones, but just to clarify: 1) While there are already new approaches to CSS via Webpack and CSS modules which in a way completely invalidate the term 'necessary', I've worked on some apps at said company that literally required CSS preprocessors. It would have been an organizational nightmare otherwise, considering the size and the scope of some of the asks. 2) Build tools encapsulate NPM, just like Make encapsulates bash (in a way). Coordinating a large team using shell scripts or cramming everything into package.json is never fun, though I do prefer NPM for smaller, more focused projects where each dev is on the same skill level. The point is: these tools have their purpose, there is a ton of documentation around them, and even if they are not the best tools for the job it is the frontend developer's role to research and evaluate their merit rather than dismissing them outright.

bastijn 11y ago
As with most things in life things are not that black and white. You are referring to the BFED extremists whilst the article is maybe referring too much to the cool frontend extremist. I work for a large medical company in its platform department and for any third party package or framework we definitely consider if it is really worth adding it, or if we can do this ourselves. Sure, things like sass we take, as we do with grunt. But we have serious issues managing our resources (fte) and backlog items. Many teams, even within our company, all want a different new cool technique. They want angular so we made directives on our UI toolkit. Another suddenly used dojo so we made wrappers for that as well, next we had ember, backbone, and soon angular 2.0 no doubt. We test the angular directives with jasmine, the JQuery with QUnit, and have saltarelle in the party as well. Next come the just out of beta frameworks as meteor, sure you can work with meteor and our REST api services but minor support is only officially added in 1.2 (not even out yet). O, less is much better than sass, give me less, no wait typescript! You are missing out if you don't use react! O, and nodejs and Mongodb not postgres! We hear it many times, as many as we have customers actually. My point, there is a middle ground here. Teams have a limited amount of resources and you have to balance the supported techniques with actual functionality. As always, choose the techniques that work for you, not what is trending (new) or well backed (old) just because. I guess big companies should be more boring than small entrepreneurs. Rather not have the aviation software of the plane I make my business trips woth run on beta frameworks.

by cnp 11y ago

bastijn 11y ago

As with most things in life things are not that black and white. You are referring to the BFED extremists whilst the article is maybe referring too much to the cool frontend extremist. I work for a large medical company in its platform department and for any third party package or framework we definitely consider if it is really worth adding it, or if we can do this ourselves. Sure, things like sass we take, as we do with grunt. But we have serious issues managing our resources (fte) and backlog items. Many teams, even within our company, all want a different new cool technique. They want angular so we made directives on our UI toolkit. Another suddenly used dojo so we made wrappers for that as well, next we had ember, backbone, and soon angular 2.0 no doubt. We test the angular directives with jasmine, the JQuery with QUnit, and have saltarelle in the party as well. Next come the just out of beta frameworks as meteor, sure you can work with meteor and our REST api services but minor support is only officially added in 1.2 (not even out yet). O, less is much better than sass, give me less, no wait typescript! You are missing out if you don't use react! O, and nodejs and Mongodb not postgres! We hear it many times, as many as we have customers actually. My point, there is a middle ground here. Teams have a limited amount of resources and you have to balance the supported techniques with actual functionality. As always, choose the techniques that work for you, not what is trending (new) or well backed (old) just because. I guess big companies should be more boring than small entrepreneurs. Rather not have the aviation software of the plane I make my business trips woth run on beta frameworks.