5 ms·

> someone not ready to handle the incredible momentum of the industry The momentum of the industry certainly presents some credibility questions, but I'm not a

> someone not ready to handle the incredible momentum of the industry The momentum of the industry certainly presents some credibility questions, but I'm not as sure as you are if they're about anyone who isn't content with a treadmill as their professional lot. Here's big quote of the article: "The BFED will develop a site based on the context of the problem and provide a solution accordingly." A BFED isn't necessarily someone who's reflexively resistant. Skeptical, maybe, because another way of describing the "momentum" of the industry would be that it's filled with tools whose adoption is often carried along by their own adoption/social proof as much as their unique merits as solutions (and that's the good case, we're not talking about the problem of hyped products whose merits might be deeply in question). And if CSS preprocessors are an example of industry momentum presenting necessity... well, I've worked on lots of projects with LESS and SASS and lots without. They can be nice, but there's no way I'd draw them inside a circle of necessity. There's a set primary problems they can address relating to keeping source keystrokes down and keeping values defined in single places. They tend to produce some of their own problems (emitted code size and source mapping). There are other solutions a good team that knows CSS and a good text-editor well can use -- good enough I'd be willing to bet on such a team's ability to keep up with (or surpass) than a team that reflexively uses LESS or SASS and considers their problems solved because that's How We Do Things Now™. What about build tools? http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt... http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool... Not a repudiation of the concept but the "momentum" of the industry has given us some questionable implementations. And they're hardly new ideas being born. They're new implementations. Any developer worth their salt is going to think first about their problems, and second about whether these new implementations should be adopted.

thebfed 11y ago
This.
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.

thebfed 11y ago

This.

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.