The boring front-end developer

by edwinjm • 11 years ago

165 142 11 years ago

vilmosi8• 11 years ago

Good article, I agree with a lot of this, but I can't help myself from commenting.

>> When given the choice to add a preprocessor (e.g. LESS, SASS, CoffeeScript etc) to the technology stack, the BFED realises there is a deeper impact beyond just "writing less code". Will it be harder to onboard developers? Will debugging code be more difficult? If the answer to any of these questions is yes then the BFED will say no to preprocessors.

Really? You will ignore the many many advantages of pre-processors because it will be harder to train new people? Come on...

>> Furthermore, the BFED realises that Single Page Applications cause severe problems and that by avoiding them and leaning on the server appropriately provides a better experience and reach.

That's a bit one sided. There's a time and place for SPAs, you can't just dismiss it entirely. Every web app today should be an SPA.

Edit: I should clarify that by webapp I don't mean website. There seems to be some confusion.

xwkd• 11 years ago

I agree with your first point. Pre-processors, especially in the CSS realm, are so intuitive that there should be negligible training overhead. I believe they should be used past a certain threshold.

I disagree with your second point, however. Single page applications are good for pages with a high amount of short, repeated interactivity where concurrency and frequent status updates are prioritized. However, there are plenty of applications that I use where I prefer to have a workflow built on discrete states (pages). They typically perform better in terms of rendering time and latency, both in terms of request and user action. (Just compare reddit's mobile beta to their previous mobile site. I still type in /.compact because I can't stand the new SPA.)

vilmosi8• 11 years ago

>> Single page applications are good for pages with a high amount of short, repeated interactivity where concurrency and frequent status updates are prioritized

That's what I understand by webapp. Web sites (such as reddit) should stay server based.

jasonlotito2• 11 years ago

With regard to the preprocessor question, I didn't read that as condemning preprocessors. Rather, it was in answering the question. Let's use LESS as an example

Will it be harder to onboard developers?

No. LESS is similar enough and we've automated the build process, so it will not be harder. People that can write CSS can learn LESS easily.

Will debugging code be more difficult?

No. Again, the similarities are already well established, and most debugging will happen within the browser. The tooling already exists to make this easy.

To me, harder doesn't mean you won't have to learn something new, but it's actually more difficult. And that entirely depends on how you have things setup and what tooling you have. This does mean that if I invite LESC and want to use that instead of LESS, it will be harder to use precisely because the tooling isn't present.

alanh7• 11 years ago

Sounds like you are desperately reading something into the original article which just isn't there. The author is clearly saying to skip the preprocessors, and this is a really backwards and ignorant position to take in 2015. CSS has a some major weaknesses and Sass/LESS do a great job patching those holes.

vezzy-fnord• 11 years ago

Controversial opinion, but I myself use CSS preprocessors quite sparingly. I actually see nothing wrong with the CSS syntax. I like the fact that CSS is (almost) nothing but a bunch of named key-value pairs. The real issues have always been semantic, in the subtleties of the box model, which Flexbox is addressing somewhat, though more daring ideas like constraint-based styling are still niche.

Just look at the LESS example on the front page. The compiled output is simpler than the source you're writing. I find having some code duplication to be an acceptable trade-off for turning a basic declarative configuration language into a chimera DSL that must be incorporated into the build process.

The more a configuration language strays away from being declarative, the less desirable this becomes.

sanderjd2• 11 years ago

I think "some code duplication" massively understates it. Being able to use named variables for colors is on its own enough of a win to make up for whatever truth there is in the "harder to train developers" downside. The many other wins make it a no-brainer.

losvedir• 11 years ago

I'm sort of coming around to this perspective as well. Ever since I read this article[0] on more of a APL/J/K style to CSS (the author's blog's CSS looks like this[2]), I've noodled with the idea of doing straight CSS again, in this pretty condensed format. It's kind of shocking at first, but does have its own charm.

[0] http://prog21.dadgum.com/200.html [1] http://prog21.dadgum.com/p21.css

pjungwir• 11 years ago

Ironically in the context of the original article, it's precisely when you're trying to support IE 5+ or 6+ (or even more modest goals) that less/sass is really valuable, since you can generate chunks of CSS values with all the browser prefixes/hacky workarounds/etc, and still be able to think about things at a higher level.

BadassFractal• 11 years ago

> > There's a time and place for SPAs, you can't just dismiss it entirely. Every web app today should be an SPA.

I feel like this is a joke or amusingly unintentional.

vilmosi8• 11 years ago

Honest question, what's wrong with SPA?

alanh7• 11 years ago

Yes, hugely ironic. “Listen, these things are never black-and-white. [pause in which audience expects a call for careful consideration, case-by-case.] They are always white.”

fuzzywalrus• 11 years ago

This should phrased about how much you lean on preprocessors. Sass is more more intelligible than regular CSS in many circumstances unless you're trying write everything as programmatically as possible. Its easily to write a For loop that spits out a grid but may make look like greek to a junior dev.

CSS preprocessors are unique, with LESS and Sass, you can write straight CSS and use its wonderful concatenation through imports, or just its nesting or perhaps simple variables for colors. There's so much benefit that I can't imagine not using them.

michaelbuddy5• 11 years ago

people act like once you get the team on board it will all start rolling, EXCEPT that there are a lot of projects where people come and go, people are temp, permanent and everything in between, changing constantly.

Of course there's documenting right? Except you document and do this fantastic job training but when it's all set and done, technology has moved on when the project wraps and there's already something better that can't coexist with the method you used.

Preprocessors also have disadvantages, not just training. Every time you abstract something, then abstract it again you are risking that what comes out could be problematic and harder to fix.

think about this. in the end, the browser is displaying based on the final CSS. You inspect the final css. If you're trying to fix something, you have to discover it, then work backwards to it's source. Inspect tools show you what's there and what you have to edit. But it takes yet another set of steps and complexity to work backwards to your css before it was processed.

make sense? So tech moves on and new complexity and longer problem solving procedures are introduced. Yay. No wonder there's an attraction to being boring.

To rework a quote from bruce lee for this. The guy who practices one kick a thousand times is much more formidable than the guy who practices a thousand different kicks one time.

woah5• 11 years ago

You might be interested to learn of source maps.

aesthetics1• 11 years ago

While interesting, we cannot all be BFEDs. The reason the BFED exists is because the non-BFEDs pushed the envelope years ago to make what the BFED now relies on standard.

xb• 11 years ago

Boring has its place, and certainly can add a lot of value to a project. If everyones goals are aligned in creating a rock solid web site or app that never needs refactoring and has 100% legacy browser support, then boring is great.

Some of us are attracted to new technologies, and appreciate learning the lessons of what advantages or disadvantages come from building the same type of site or app with a different framework or technology stack. Especially those of us who aren't yet mature enough to write our own apps without the guidance of frameworks, and have not had a chance to work with all of the different possible approaches.

I think a healthy balance can be struck between the type of stability gained from the 'boring' approach, and the types of gains that can be realized from newer 'non-boring' technologies. Sometimes supporting IE6 is not a concern at all, and learning new language features from ES6 is an attractive proposition.

If doing front-end development were boring, I don't think I'd be as interested in doing it.

serve_yay4• 11 years ago

A nice thought, but front-end tools are not really mature enough to be boring, sorry. I mean one could credibly say "oh I'm so boring, I use jQuery everywhere" but... that's not actually going to be a boring development experience. It will be exciting, in the bad way.

hiphipjorge• 11 years ago

The problem with jQuery is not so much jQuery itself, it's the architecture of sites/apps written with many jQuery plugins and no code organization. I wrote many apps using simple JS modules (with browserify) using jQuery for DOM manipulation and the approach worked great. While I don't really use jQuery anymore, it's great for what it aims to do: DOM manipulation.

The point is that exciting development experiences (in the bad way) are usually due to developers not really not knowing what they're doing. Picking your tools is part of that and no tool will, inherently, provide a bad development experience.

serve_yay4• 11 years ago

The problem with jQuery is not so much jQuery itself, it's the architecture of sites/apps written with many jQuery plugins and no code organization.

Yes, precisely. But you could conceivably call such a ball of mud "boring" because there's nothing cutting edge about it.

rawTruthHurts• 11 years ago

I couldn't help but read the article as "hype beats reliability, and that's the ways it should be"

stupidcar• 11 years ago

The boring front-end developer doesn't get paid very much.

michaelbuddy5• 11 years ago

opinion

teacup50• 11 years ago

Neither does the exciting front-end developer.

atinoda-kestrel2• 11 years ago

Oh he does. Just only while the VCs are writing checks. ;)

carsongross2• 11 years ago

“As a Lead JavaScript Engineer, I try to get my team to write as little JavaScript as possible.”

Yes.

Let me show you mine: http://intercoolerjs.org/

Not mature enough yet to be completely BFED, but that's the goal.

serve_yay4• 11 years ago

So you move the JS into the markup, with special attributes. Hmmph.

carsongross2• 11 years ago

Hmmph, indeed.

However, it is a much simpler conceptual model than doing it w/ javascript off in some jQuery onLoad function: web requests just hit URLs like they always have, download HTML content like they always have and swap it into a rectangle, like they always have. It's just that the rectangle doesn't necessarily have to be the entire screen like it always has.

The behavior of a given bit of HTML is fairly localized, which makes it easy enough to understand what, say, a button does, and the server side controllers and templating work like they always have.

So, all in all, I'd call it maybe a 7/10 on the curmudgeon scale.

kylnew• 11 years ago

Hmm pretty broad strokes. I think its constantly important to scrutinize ourselves and our tech decisions like this though.

I don't think I'd ever take a front end job that doesn't use a CSS preprocessor, though I understand it was part of a larger example.

It seems like the best product might come out when a BFED and CED need to work together and have the appropriate chemistry not to kill each other.

j_baker• 11 years ago

Blah. Yet another "new-fangled technologies have no place" post. Granted, there's a grain of truth to the core thought. As I've become more experienced, I've seen more frameworks and libraries that re-invent the wheel and solve problems that have already been solved long ago, albeit in a trendier manner.

But at the end of the day, software engineers are technologists. Our job is to create and consume technology. Being afraid of new technology is counter-productive.

phil248• 11 years ago

"This is the technology industry, we don't have time for new technology!"

krapp2• 11 years ago

The industry that still argues about which text editor from the 1970s is the best tool to code in has a problem with rapid paradigm shifts?

I'm shocked.

JustSomeNobody2• 11 years ago

I didn't read that in the article. Being a technologist means know when NOT to use a technology as much as knowing when to use it. There're way too many developers who read links from HN and try and push the javascript framework of the weak on everyone at their job without fully comprehending the consequences of their decision. That's not being a technologits, that's being stupid.

0xdeadbeefbabe4• 11 years ago

and push the javascript framework of the weak

(emphasis added)

atinoda-kestrel2• 11 years ago

There're way too many developers who read links from HN and try and push the javascript framework of the weak on everyone at their job without fully comprehending the consequences of their decision.

One good question to ask yourself when evaluating a framework is this:

If the project/company dies out tomorrow, and we're tied to this thing, can we take it in-house and pick up maintenance?

If the answer to that is no, not even long enough to migrate to something else, then boy, you'd better be damn sure that the team that develops it isn't going to go away or lose interest. Hence my skepticism with many, many Javascript "framework of the week" projects. There's just far too many out there that have died out after a year or two for me to blithely accept whatever the new hotness is.

rimantas• 11 years ago

Reinventing the wheel is only a part of the problem. The other is that the wheel is spinning in the same place. And I even suspect that the cart is no longer there.

thebfed5• 11 years ago

New != bad && New != good

Analyse critically and deliberately. Be conscious of decisions.

comrade1• 11 years ago

I always tell my guys that I don't want them to think outside of the box. We should be firmly inside the box. (This is our inside joke, but there's also truth to it).

smacktoward2• 11 years ago

“As a Lead JavaScript Engineer, I try to get my team to write as little JavaScript as possible.”

I would argue that the wisdom of this goes beyond JavaScript to all programming.

Or, to put it slightly differently: how can you tell the difference between an inexperienced programmer and an experienced one? The inexperienced programmer thinks of every line of code as an asset. The experienced one thinks of every line of code as a liability.

vlunkr3• 11 years ago

That's a great quote! (the last line) That's something I've experienced but hadn't really been aware of until I read that.

brlewis2• 11 years ago

Perhaps you want this 1988 quote from Edsger W. Dijkstra:

My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

akilism2• 11 years ago

double edged sword though right?

we should be striving to write the most readable and easily understandable code. neither the most lines or the fewest but what can be easily proven and reasoned about.

marcosdumay• 11 years ago

Yes, ok. Some lines are more of a liability than others.

atom-morgan3• 11 years ago

This may all be true but at the end of the day a lot of companies aren't looking to hire a BFED.

michaelbuddy5• 11 years ago

yes they are, all over the place.

atom-morgan3• 11 years ago

My own experience on the job market is largely the opposite even if they say otherwise.

savanaly• 11 years ago

The BFED realises that while not all experiences will be identical, all browsers can be used to consume a website, even gasp, IE6 and below.

I don't understand this point. He must be speaking of degrees, not a binary decision, right? Surely he wouldn't advocate supporting Netscape 1.0?

When given the choice to add a preprocessor (e.g. LESS, SASS, CoffeeScript etc) to the technology stack, the BFED realises there is a deeper impact beyond just "writing less code". Will it be harder to onboard developers? Will debugging code be more difficult? If the answer to any of these questions is yes then the BFED will say no to preprocessors.

Covered by another commenter, this is way too simplistic. There's a tradeoff between the benefits of a technology and the increased complexity of your app and increased training time for new hires. I highly doubt a great BFED would refuse to make any tradeoffs that might increase complexity or require more training. We are professionals after all, some learning of tools is expected of us!

The BFED realises that users have different abilities and preferred ways of using a device, whether its a mouse, finger, thumb, screen reader, keyboard or a combination of all, websites should be consumable no matter the audience, screen size or capability of the browser.

Yep, though this seems more like a point in the cool front end developer's camp. A healthy percentage of the huge amount of JS libraries that are released all the time these days (and bemoaned on HN and blog posts like this one) have to do with accessibility and responsive design for multiple interfaces.

The BFED embraces the constraints and limitations of the browser so that he/she doesn't find him/herself in a world of Adaptive Design and UA sniffing because that world is horrible, ill-advised and costly.

Due to my own inexperience I'm not quite sure what they're on about.

The BFED will also suggest the use of native form controls realising that browsers will enhance the experience where possible, particularly on mobile, and doesn't try to control the look and feel too much as he/she knows that the brand will not suffer because of that decision.

A good point, and I tend to advocate for those too. But it's sort of a call that gets made above the code monkey's pay grade in my experience.

The BFED will also suggest that links are styled as such, and with underlines, so that users can identify them within copy.

Subjective. Seems like engineers tend to prefer this style and assume everyone else does too.

The BFED will carefully select third party code based on the quality of the code itself by reviewing source code, not based on the popularity of said code. He/she favours reliability over popularity every time.

Fair enough.

The BFED will adhere to the following quote (by Anon): “As a Lead JavaScript Engineer, I try to get my team to write as little JavaScript as possible.”

I agree.

Furthermore, the BFED realises that Single Page Applications cause severe problems and that by avoiding them and leaning on the server appropriately provides a better experience and reach.

Definitely disagree, but to even start on that discussion is way beyond the scope.

vdaniuk• 11 years ago

This "manifesto" doesn't even try to consider tradeoffs. There is no analysis of stakeholder preferences or path-dependent UX/UI evolution or personal projects for fun and learning. It doesn't consider neither business requirements nor developer satisfaction.

However, the article is quite good at hipster shaming, so it gets upvoted to HN front page. A classic example of link bait tailored for its audience.

It's telling that your comment with point by point discussion of BFED propositions is at the very bottom, btw.

He/she will not just use [insert buzz word here] to improve his/her chances of finding another job based on the current technology fad in order to increase their day rate.

And this quote is just... wow.

michaelbuddy5• 11 years ago

what is "path-dependent UX/UI evolution" ?

nahiluhmot• 11 years ago

The BFED realises that while not all experiences will be identical, all browsers can be used to consume a website, even gasp, IE6 and below.

Where would we be if we supported all legacy software? Does there not come a point where cutting support for a class of platforms is a good thing? This article makes some good points, and I think a lot of frontenders (myself included) would benefit from being a bit more "boring", but this article is going a little too far the other way.

DCoder• 11 years ago

Does there not come a point where cutting support for a class of platforms is a good thing?

For example: An article was linked on the HN frontpage a couple days ago about how CP/M reserved names (COM1, etc) still live on in ASP.NET MVC these days. https://news.ycombinator.com/item?id=9871014

minitech3• 11 years ago

It’s not so much about supporting legacy software as having something that’s likely to show something in any browser, from Firefox to IE6 to Dillo to Lynx.

akilism2• 11 years ago

Am I supposed to worry about IE6 when Microsoft doesn't? Can we draw the line at supporting things when their creators give up on them?

Sakes• 11 years ago

Front-end is crazy, so I can sympathize with the author's desire to use it minimally.

I think if this really is your perspective, and you are waiting for the front-end chaos to settle before investing heavily in front-end development, you should just stick to server side pages and use jQuery to sprinkle in some JS sugar.

>> Be a great front-end developer. Be boring.

I think you could rephrase this to...

Be a great front-end developer by being a server side developer.

His arguments:

Browser support - me: situational but makes very good points.

Preprocessors - me: completely disagree

Accessibility - me: very good points but not restricted to any one type of developer (web apps, spa, server side templates, native mobile, native desktop)

UI design - me: totally agree with his point on browser sniffing, a dangerous game

Third party CSS and Javascript libraries and frameworks - me: seems like he should avoid these altogether

UI architecture - me: this really seems like an opinion that is easily debatable

CV - me: a good voice to have on your team regardless of tech / project requirements.

Animats• 11 years ago

There are times when you need heavy machinery running in the browser. It's impressive to see a water surface simulator or some live graph running in the browser. That's rare, though. Many sites that would work perfectly in HTML 3.2 have way too much machinery behind them.

Much of the heavy machinery is there to support two simple functions - adapting to screen size, and scrolling. That's because the HTML5/CSS model does not natively do either very well. Other machinery is there for form input validation, which HTML does not support directly.

There is, of course, the other major use of Javascript - silently obtaining information about the user and sending it somewhere to be "monetized".

cnp5• 11 years ago

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.

hiou• 11 years ago

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.

Azkar2• 11 years ago

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.

copperx• 11 years ago

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.

nkassis• 11 years ago

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.

serve_yay4• 11 years ago

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.

cnp5• 11 years ago

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.

lojack• 11 years ago

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.

wwweston• 11 years ago

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.

thebfed5• 11 years ago

This.

cnp5• 11 years 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.

snarkyturtle3• 11 years ago

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.

niutech• 11 years ago

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?

shalmanese• 11 years ago

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.

vlunkr3• 11 years ago

I don't see the need to be so one-sided. You can be "boring" in some ways and still use new technologies when it's appropriate.

caltonji• 11 years ago

reminds me of http://motherfuckingwebsite.com/ (NSFW language)

keithpeter• 11 years ago

I always hear that page in Gil Scott-Heron's voice. But then he was very sparing with the bad language indeed so that when used it meant something.

I do miss the fast-web (you know, text and pictures)

EnderMB• 11 years ago

For those of us that work on bog-standard websites for clients, I definitely agree with some of the points. I've worked on numerous projects where the latest and greatest tools at that time were used wherever they could have been used, and more often than not six tools are being abused to do the work that a reasonably simple build script would have achieved.

With that being said, all tools have their place, and it's all about realising what that place is. For example, using Foundation when your client has expressed a desire for their site to work in IE6 because their clients all work in large law firms and are limited to XP and IE6 (a genuine use-case I've had to build for about three years ago) your tool will probably fail you.

For me, it's less about being a "BFED", and more about planning your solution before you build it, something that increasingly few people seem to do. In a lot of cases where people do plan or spec work before they start it, it's done in a tool-oriented fashion. A developer will tell the client that they will build their site using AngularJS, but when the client says "I've tested this page in IE7 and it doesn't work. Please fix." they realise that a task they thought about take n hours will actually take a fair bit longer.

A boring developer gets the information they require first and picks a suitable tool for the job. If the requirements change, so be it. A boring developer will get the new requirements, and will adjust their solution accordingly. This is the kind of boring developer to be, not the kind that doesn't pick a tool because it's new.

Wintamute• 11 years ago

Hmm. There is truth to some of this, but like everything moderation is key. Use your experience to pick new tech that meaningfully improves UX, DX, maintainability or some other metric without creating problems. It does exist. Likewise, don't be the boringest of boring developers because you'll miss out on key innovations and your product will suffer. Unless, that is, you want to make a name for yourself as Supreme Leader of BFEDs for career advancement purposes, in which case host a clickbaity blog about it and argue from a highly polarized position ... oh, wait

alanh7• 11 years ago

First things first: This article presents a lovely sentiment — although any argument against CSS preprocessors is a losing one — and is a timely reminder to focus on the things that matter.

However…

When was this published? There’s no date anywhere on the page or even in its source code, but he mentions supporting "IE6 and below". This is actually no longer possible if “HTTPS” is a requirement, as the best version of SSL supported by IE6 is SSL v.3 which suffers from a fatal vulnerability and supporting it on your servers puts your users at risk.

There’s also no need to support IE6. Now that XP is this-time-we-mean-it officially dead and unsupported, you can't even run a fully patched OS with IE6 on it.

Edit: Via another page on the author's site, I was able to find a publication date of 1 October 2014 for this article. (This just barely gets Mr. Silver off the hook, as the final-nail-in-IE6's-coffin SSLv3 bug POODLE was announced a mere 2 weeks later. That is, if we ignore the "and below" remark. No one has tested their site in IE5.5 in damn near a decade now.) Please, authors: Include the full date with your written works. (Leaving off the year is a shamefully common anti-pattern, as it's the most important part!)

osconfused• 11 years ago

This makes me wonder if there is a SEO bump/penalty associated with article dates.

alanh7• 11 years ago

Doubtful – i think it's mostly oversight, but I’d be curious to hear from those perpetrating the trend!

at-fates-hands• 11 years ago

The debate on preprocessors should be moot. As an agency, you can hire people who already know and use it everyday - thus the onboarding and debugging costs become irrelevant.

If you're not learning or using preprocessors, the only person you're hurting is yourself. You're just self selecting yourself from future work considering so many places use these now as a standard.

curiousjorge• 11 years ago

WISYWIG UI builders that are slowly picking up momentum will eventually end up commoditizing this role. There will come a day when a product designer can just create the UI from mockups, generate tested, clean plumbing code much faster and more reliable than getting a front-end developer to do it. I would start learning to get proficient with upcoming UI builders and whichever framework it ends up supporting (most likely React).

theVirginian• 11 years ago

Potentially, but the people with the ability to understand the code that is being generated will always have more value than the people who don't. WISYWIG editors are useful and quick but you are ultimately limited to the what the editor allows you to build.

minitech3• 11 years ago

Yes, I remember when FrontPage achieved this very same revolution.

woah5• 11 years ago

I've never seen a wysiwyg tool that can cope with hand modifications to its generated source code. This would probably require strong AI.

crucialfelix• 11 years ago

Moderation in all things. Don't be boring, don't be trendy.

kdamken• 11 years ago

Anyone who's ever actually written a website using vanilla CSS and then gotten to write a site with Sass knows that not using a preprocessor in this day and age is insane. It makes things 1000x easier to write and more importantly to maintain.

Writing vanilla CSS after using a preprocessor is torture.

omouse3• 11 years ago

Boring front-end developers also aren't involved in the project planning or design process so they're low-status. Of course I expect them to follow the spec and do things the boring way, because that's what they're paid to do. New tech? That's a new risk, better find someone else who will do exactly what we ask and not try to "improve" things.

What I see from the frontend developer community with all these new frameworks and tools is a rebellion against project managers and clients and the whole agency model which makes creating websites the most bland process imaginable.

Every single thing listed in the article is more fun. Being boring is fine but you better be paying the dev either very little because you don't really value them, they're simply a machine for turning your ideas into code; or you pay them a lot because you know if you don't they'll leave and take their great ideas and work for a competitor or start consulting and stealing clients.

awkward2• 11 years ago

This article is terrible. It argues for awful web and UI development, and seems to be doing it entirely out of some kind of perverse pride.

The first item in this list recommends support for IE6 or below, a decision which will massively balloon your project budget for a shot at roughly %1 of the total browser market. Microsoft itself has launched multiple campaigns to get developers to stop supporting IE6.

Charitably, I'll assume the author doesn't want to lump javascript compilers in with preprocessors, although his arguments against seem like they might suggest he does.

Following that, he recommends development using progressive enhancement, which was developed as a best practice largely to wiggle out from the constraints imposed by IE 6 during the eight years where it was crushing the shit out of the web industry.

As a closer, he suggest that you not learn "buzzword" technologies in order to increase your day rate.

In summary, he wants you to target ancient technology, eschew any front end build process, live in fear of the ancient technology you've agreed to support, and then not get paid for it.

michaelbuddy5• 11 years ago

Yeahhh, you've not written a very good summary of what he wrote. But I hope it felt good to get a word in at least.

awkward2• 11 years ago

Acceptable risk levels vary from project to project, and often it is a good choice to de-risk your UI so that you can budget risk to something more important to project success. I am currently working on a manufacturing support project that uses jquery in a progressive enhancement style, for instance, because that's the most comfortable level for the team, and we prefer to have the risk in the part of the code that gets into the business processes. This means we use a framework, LESS (for bootstrap UI) and we support web standards. We do not support IE6 because one cannot legally purchase a computer that runs IE6 in 2015.

The article is making statements that claim to be conservative, but were too conservative for businesses supporting them to survive. In 2006.

This is a bad article. I had trouble finding the date on it, but on the site's index it states that it was written in 2014. This makes it violently out of date at the time of it's writing. You should not treat it like a good article because it flatters your prejudices about new-fangled web development, because most of the content of the article is flattery. Not only that, it flatters you for not paying attention to what is going on. That should be a bad sign.

scelerat• 11 years ago

In my experience, any learning curve for the popular CSS preprocessors (SASS, LESS) is dwarfed by the maintenance and productivity gains. The only downside to them is that thoughtless use of them can lead to very bloated CSS builds. But onboarding? LESS and SASS, fundamentally, provide what CSS should have provided from day one: nestable rules/statements, macros, and variables.

Other than that, +1, good read, will share.

roneesh• 11 years ago

When I teach HTML/CSS/JS, I tell my students this: "put as much functionality into HTML/CSS as you can, and use JS as a frequent, but last resort". I think that sums up the benefits of this article without carrying along any of the needles anachronisms (use pre-processors, they're great). With animations, transforms and html5 form validations, you can avoid JS for longer than you think.

JamesBarney• 11 years ago

"The BFED will carefully select third party code based on the quality of the code itself by reviewing source code, not based on the popularity of said code. He/she favours reliability over popularity every time."

The power of popularity should not be underestimated, there are very large and powerful network effects that popularity brings to the table.

Popular code

  -has more tutorials/blog/books written about it

  -has more Q & A on Stackoverflow

  -is easier to hire for

All frameworks have problems with better designed frameworks having less. For popular frameworks you're in luck, because somebody has already figured out all the work-arounds to common problems. But on an unpopular one you have to figure out all those work-arounds yourself.

thebfed5• 11 years ago

McDonalds and Coca Cola is very popular - is it good for you?

hlfcoding• 11 years ago

The irony is implementing progressive enhancement and accessibility is anything but simple, and probably just as big a maintenance burden as custom form controls, and comes with debatable gain.

Each project and team and project is different, there's no constant requirements in frontend, in tools or features. Some teams may be super unproductive without Sass. This post is very much written from the bias of older trends, and from a time when the frontend had fewer real concerns other than styling a document.

The boring front-end developer

Related Stories