Hacker News Reader

Comment by cnp | Hacker News Reader

I worked for a few years at an agency that adhered very closely to these principles, and you know what? When things started to rapidly change around 2013 everyone was consumed and overwhelmed, and when it came time to necessarily onboard them on new technologies such as build systems, css preprocessors and the like, the skepticism was so profound, and caused such a problem for those of us looking to make everyones life easier, that the process took way longer than it should have taken with loops and hoops that I hope to never have to repeat.

After that experience, I fully equate the BFED with someone not ready to handle the incredible momentum of the industry and, for better or for worse, would never consider hiring them. There are too many good ideas being born right now to risk falling into rigid patterns of thinking.

View on HN

> 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/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.

This.

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.

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.

There is a great KISS principle. When you can effectively develop a website using only vanilla CSS & HTML and a bit of JS, why use some overhyped fancy tools like grunt, gulp, bower, less, sass, yeoman, etc.? I can open vim or any other code editor on any PC and start coding web pages right away, without spending hours on configuring complex toolchains, writing build scripts and so on. If web pages could be done that simple oldschool way 5 years ago, couldn't they be done the same way today?

Put it this way: there are still great C99 programmers who make fast programs, are they useless only because they don't use C++14 with all bells and whistles?

> There are too many good ideas being born right now to risk falling into rigid patterns of thinking.

The problem is that there are too many ideas out there, period. It's almost impossible to separate the wheat from the chaff. See: JavaScript libraries.

Definitely an issue but it shouldn't prevent you from using some tools. For example, I've mostly stayed away from compile to JS languages except for ClojureScript (for personal project) and TypeScript because I see real value in both of them. TypeScript has been a massive boon to help with the largish client side app I work on professionally. Helps keeps the code base somewhat sane and easy to develop in.

CSS preprocessors have been similar, cutting down on duplication that leads to potential bugs is hugely useful.

Obviously taking small steps and sticking to things as long as there is no major benefit from switching helps. No reason to jump from Angular to React or whatever is new if it's fulfilling your needs.

I wish I was using TypeScript right now; we're using babel for ES6 transpiling and I've found a situation where a particular importing of a module doesn't work correctly. It appears correctly when I run it through the eslint tool and babel/webpack don't seem to complain when compiling, but in the browser it doesn't work.

When trying TypeScript and CoffeeScript I never ran into issues like that.

OMG, Webpack... you love it and you hate it.... and it never gets easier!

But it does not follow from that that the wheat and the chaff are pretty much the same since they came out around the same time.

A pragmatic solution to this problem is to follow certain key developers closely on Github and Twitter, the ones most aligned with the patterns and issues you or your company are addressing. The repos they star and the tweets they forward give you a sort of inside look into where the industry is going; this inspires confidence in decision making.

I watched a company almost go under(shrank to almost no employees) after exactly what you described. The BFEDs(including the CTO) refused to update their skills and the company tools/stack and the company was beaten out by competitors.

I worked at an organization that didn't let us use stored procedures or OOP because the older devs couldn't understand them (it was a Navy contractor, so there were guys that had been there 15+ years).

If you decide not to use a technology because the developers can't or are unwilling to learn them, you've got bigger problems than technology choices.

I realize you were just making a specific observation about one situation, but it's worth noting that being an "older" developer (which at 15+ years experience would be late 30s) in no universe means that the developer doesn't know things.

Indeed, the irony is that many shops full of junior FEDs found databases and stored procs so intimidating that we saw the rise of things like MongoDB. Even if it completely sabotages any medium or long term plan, if all you know is JavaScript and have very naive notions about the uses of data, seems great.

There were definitely "older" devs that wanted to do those things, but they didn't have the 15 years of tenure to be able to make those decisions. I should rephrase to say that if your devs don't want to learn new things, they probably aren't in the right field.

I'm at yet another place where every one does their own thing and once you get past 2 devs this quickly becomes an issue. But heaven forbid you want to set aside time for training and making sure everyone is on the same page with regards to skill and methods.

I'd say you also have a problem if one or two devs want to use a tech but aren't also willing to train the rest of the devs in them (passing around links to a few tutorials doesn't count as training).

Almost all of my "successes" in bringing people over to more modern practices centered around actual training. Meaning, creating sample apps and arguing effectively with upper management and the devs that I worked with daily.

CRUD isn't technology anymore.

For about 4 months I worked at a place where the senior dev's first question regarding any technology would be whether or not it could be done in VB6 (this was circa 2009 or so). If it could, he'd make the decision that it just had to be done in VB6 because that's what the shop was using at the time.

I've seen PHP projects that require NPM to compile the css and js...

All front-end devs should be able to switch to that BFED mode though, especially on pages that don't _need_ to be fancy. This helps with cross-browser compatibility and pagespeed. You could still be fancy, but only as a necessity and even then it should be layered on the BFED-side.

The problem with devs nowadays is they skip the BFED and just jump into SPA's without knowing how to make a well-working website without tons and tons of sass/js.

I think this is just one of those things that every developer needs a healthy balance of. BFED qualities are required to ship code on time with minimal defects. Using the latest-and-greatest technology helps drive growth as a developer, but introduces risk.

For me it's a matter of identifying new technology that is valuable to invest my time into learning, and knowing when it's appropriate to learn the new technology.

I think the ideal is a "tick tock" strategy where you're either allowed to innovate on tooling or innovate on product but never both at the same time. Reserve interesting tooling experiments for small, well defined, non user facing systems so that your team becomes familiar with the pros/cons, then apply it to large scale core functionality once you've gained the experience.

Reply on news.ycombinator.com