11 ms·

The boring front-end developer

165 points by edwinjm 11y ago

vilmosi 11y 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 11y 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.)
  - vilmosi 11y 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.
- jasonlotito 11y 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.
  - alanh 11y 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.
    - thebfed 11y ago
      I am saying,consider all the disadvantages too. If you still think it's beneficial after that, at least it's a conscious decision.
    - jasonlotito 11y ago
      Sounds like you are desperately reading something into the original article which just isn't there. The author is clearing saying consider all the disadvantages too. If you still think it's beneficial after that, at least it's a conscious decision. Your comment has a some major weaknesses and reading does a great job patching those holes.
      - alanh 11y ago
        > Will it be harder to onboard developers? Will debugging code be more difficult? If the answer to any [sic] of these questions is yes then the BFED will say no to preprocessors. — TFA Read literally, the paragraph says “If there are any downsides, do not use preprocessors.” A more balanced approach of weighing upsides and downsides is not supported by the original text. If the author wanted to say something different, he can and should have done so. I encourage him to change his call to action from “say no to preprocessors” to “be conscious of decisions.” It’s much more defensible and realistic!
- vezzy-fnord 11y 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.
  - sanderjd 11y 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.
    - robinson7d 11y ago
      Agreed. One example would be that using named variables, particularly set with "default" values, makes white-labelling applications much simpler.
    - thebfed 11y ago
      It's not the only downside to consider. http://adamsilver.io/articles/the-disadvantages-of-css-preprocessors/ http://adamsilver.io/articles/the-disadvantages-of-css-prepr... There are a lot of advantages to them that need consideration too granted.
      - sanderjd 11y ago
        Certainly, everything has trade-offs, but CSS pre-processors are more heavily weighted toward the positive side of the trade-off calculation than pretty much anything else I can think of, especially in the "web technologies" space. I found lots of the arguments in the OP to ring true – things often feel far too fancy, and the more "boring" stuff has major appeal – but I found the arguments against CSS pre-processors there and in the article you linked very thin relative to my experience with them after years of using raw CSS.
- BadassFractal 11y 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.
  - vilmosi 11y ago
    Honest question, what's wrong with SPA?
    - alanh 11y ago
      The author write and linked to an article on the downsides. While I haven't read it, I do rage every time I click on a link to a Blogger.com-hosted article and watch some fucking Blogger logo animating as they load a web app to show me some static text. There’s no need for anything to load before showing me the blog page. The experience has been degraded and made more fragile, not enhanced.
      - vilmosi 11y ago
        I've read many articles about SPA issues. I don't think any of them can't be overcomed. But when I say webapp I don't mean blogs or regular mostly static websites. I mean Web applications.
      - woah 11y ago
        Similar to how I hate all hamburgers because of those damn dry McDonald's buns.
    - mod 11y ago
      Nothing's really wrong with SPAs (they have benefits and drawbacks). What's wrong is making a blanket statement that "every web app" should be one. Also you're trying to draw a fine distinction between web apps and websites, which could be another discussion altogether, probably with no big agreement on where to place the line.
      - vilmosi 11y ago
- fuzzywalrus 11y 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.
- michaelbuddy 11y 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.
  - woah 11y ago
    You might be interested to learn of source maps.
aesthetics1 11y 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 11y 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_yay 11y 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 11y 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_yay 11y 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 11y ago
  I couldn't help but read the article as "hype beats reliability, and that's the ways it should be"
stupidcar 11y ago
The boring front-end developer doesn't get paid very much.
- michaelbuddy 11y ago
  opinion
- teacup50 11y ago
  Neither does the exciting front-end developer.
  - atinoda-kestrel 11y ago
    Oh he does. Just only while the VCs are writing checks. ;)
carsongross 11y 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/ http://intercoolerjs.org/ Not mature enough yet to be completely BFED, but that's the goal.
- serve_yay 11y ago
  So you move the JS into the markup, with special attributes. Hmmph.
  - carsongross 11y 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.
    - jdsampayo 11y ago
      I think you will like Angular.
      - woah 11y ago
        I think that OP likely knows angular and dislikes it.
kylnew 11y 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 11y 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 11y ago
  "This is the technology industry, we don't have time for new technology!"
  - krapp 11y 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.
    - 0xdeadbeefbabe 11y ago
      The people commenting here are not those people for the most part.
    - michaelochurch 11y 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 use emacs and avoid IDEs. That said, I have no interest in the emacs vs. vi debate. I don't care what tools you use, as long as you don't do things in a way that force me to use specific tools (e.g. enterprise environments that becomes IDE-dependent). As for me, I don't like mindless churn. This industry desperately needs to improve. It's running at about 5% (if that) of its real potential. But the constant fire drilling that comes with moving from one well-sold crappy technology to another well-sold crappy technology is really irritating, and it's part of why so many good programmers tend to move up into management.
- 11y ago
comrade1 11y 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).
smacktoward 11y 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.
- vlunkr 11y 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.
  - brlewis 11y 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.
    - talmand 11y ago
      I think the idea of reducing lines of code as a means of success can go too far. Sure, you can squeeze that block of code down a few dozens of lines of code, but then how hard is it to follow along behind you and deduce your intentions? You may be saving something today to just be needlessly spending it tomorrow.
      - mod 11y ago
        It's almost never taken too far, so generally speaking, this argument doesn't carry much weight. Also, at a few dozen lines per block, you could keep going a long way!
        talmand 11y ago
atom-morgan 11y ago
This may all be true but at the end of the day a lot of companies aren't looking to hire a BFED.
- michaelbuddy 11y ago
  yes they are, all over the place.
  - atom-morgan 11y ago
    My own experience on the job market is largely the opposite even if they say otherwise.
    - thekingshorses 11y ago
      I am hiring. http://interana.com/ http://interana.com/
      - atom-morgan 11y ago
        Unfortunately I just accepted a job offer about a week ago. Thank you though :)
savanaly 11y 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.
nahiluhmot 11y 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 11y 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 https://news.ycombinator.com/item?id=9871014
- minitech 11y 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.
  - akilism 11y 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?
    - minitech 11y ago
      The point of my comment was to say you don’t have to support old or obscure browsers specifically; just have proper content in your HTML and everyone will be satisfied without additional effort on your part.
Sakes 11y 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 11y 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".
cnp 11y 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 11y 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.
  - Azkar 11y 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.
    - motional 11y ago
      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.
vlunkr 11y 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 11y ago
reminds me of http://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/ (NSFW language)
- keithpeter 11y 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 11y 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 11y 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
alanh 11y 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 11y ago
  This makes me wonder if there is a SEO bump/penalty associated with article dates.
  - alanh 11y ago
    Doubtful – i think it's mostly oversight, but I’d be curious to hear from those perpetrating the trend!
at-fates-hands 11y 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 11y 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 11y 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.
- minitech 11y ago
  Yes, I remember when FrontPage achieved this very same revolution.
- woah 11y 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 11y ago
Moderation in all things. Don't be boring, don't be trendy.
kdamken 11y 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.
omouse 11y 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.
winnerscout 11y ago
Shut up, you faggot. Being a front-end dev is boring almost by definition. And the only time it isn't is when you can tell users witch shit clients to fuck off and go somewhere else. Faggot.
- Killswitch 11y ago
  Great way to get your point across and considered.
  - winnerscout 11y ago
    Engage.
awkward 11y 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.
- michaelbuddy 11y 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.
  - awkward 11y 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 11y 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 11y 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 11y 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.
- thebfed 11y ago
  McDonalds and Coca Cola is very popular - is it good for you?
hlfcoding 11y 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.

165 points by edwinjm 11y 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 11y 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.)
- vilmosi 11y 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.
jasonlotito 11y 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.
- alanh 11y 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.
  - thebfed 11y ago
    I am saying,consider all the disadvantages too. If you still think it's beneficial after that, at least it's a conscious decision.
  - jasonlotito 11y ago
    Sounds like you are desperately reading something into the original article which just isn't there. The author is clearing saying consider all the disadvantages too. If you still think it's beneficial after that, at least it's a conscious decision. Your comment has a some major weaknesses and reading does a great job patching those holes.
    - alanh 11y ago
      > Will it be harder to onboard developers? Will debugging code be more difficult? If the answer to any [sic] of these questions is yes then the BFED will say no to preprocessors. — TFA Read literally, the paragraph says “If there are any downsides, do not use preprocessors.” A more balanced approach of weighing upsides and downsides is not supported by the original text. If the author wanted to say something different, he can and should have done so. I encourage him to change his call to action from “say no to preprocessors” to “be conscious of decisions.” It’s much more defensible and realistic!
vezzy-fnord 11y 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.
- sanderjd 11y 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.
  - robinson7d 11y ago
    Agreed. One example would be that using named variables, particularly set with "default" values, makes white-labelling applications much simpler.
  - thebfed 11y ago
    It's not the only downside to consider. http://adamsilver.io/articles/the-disadvantages-of-css-preprocessors/ http://adamsilver.io/articles/the-disadvantages-of-css-prepr... There are a lot of advantages to them that need consideration too granted.
    - sanderjd 11y ago
      Certainly, everything has trade-offs, but CSS pre-processors are more heavily weighted toward the positive side of the trade-off calculation than pretty much anything else I can think of, especially in the "web technologies" space. I found lots of the arguments in the OP to ring true – things often feel far too fancy, and the more "boring" stuff has major appeal – but I found the arguments against CSS pre-processors there and in the article you linked very thin relative to my experience with them after years of using raw CSS.
BadassFractal 11y 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.
- vilmosi 11y ago
  Honest question, what's wrong with SPA?
  - alanh 11y ago
    The author write and linked to an article on the downsides. While I haven't read it, I do rage every time I click on a link to a Blogger.com-hosted article and watch some fucking Blogger logo animating as they load a web app to show me some static text. There’s no need for anything to load before showing me the blog page. The experience has been degraded and made more fragile, not enhanced.
    - vilmosi 11y ago
      I've read many articles about SPA issues. I don't think any of them can't be overcomed. But when I say webapp I don't mean blogs or regular mostly static websites. I mean Web applications.
    - woah 11y ago
      Similar to how I hate all hamburgers because of those damn dry McDonald's buns.
  - mod 11y ago
    Nothing's really wrong with SPAs (they have benefits and drawbacks). What's wrong is making a blanket statement that "every web app" should be one. Also you're trying to draw a fine distinction between web apps and websites, which could be another discussion altogether, probably with no big agreement on where to place the line.
    - vilmosi 11y ago
fuzzywalrus 11y 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.
michaelbuddy 11y 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.
- woah 11y ago
  You might be interested to learn of source maps.

aesthetics1 11y 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 11y 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_yay 11y 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 11y 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_yay 11y 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 11y ago
I couldn't help but read the article as "hype beats reliability, and that's the ways it should be"

stupidcar 11y ago

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

michaelbuddy 11y ago
opinion
teacup50 11y ago
Neither does the exciting front-end developer.
- atinoda-kestrel 11y ago
  Oh he does. Just only while the VCs are writing checks. ;)

carsongross 11y 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/ http://intercoolerjs.org/ Not mature enough yet to be completely BFED, but that's the goal.

serve_yay 11y ago
So you move the JS into the markup, with special attributes. Hmmph.
- carsongross 11y 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.
  - jdsampayo 11y ago
    I think you will like Angular.
    - woah 11y ago
      I think that OP likely knows angular and dislikes it.

kylnew 11y 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 11y 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 11y ago
"This is the technology industry, we don't have time for new technology!"
- krapp 11y 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.
  - 0xdeadbeefbabe 11y ago
    The people commenting here are not those people for the most part.
  - michaelochurch 11y 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 use emacs and avoid IDEs. That said, I have no interest in the emacs vs. vi debate. I don't care what tools you use, as long as you don't do things in a way that force me to use specific tools (e.g. enterprise environments that becomes IDE-dependent). As for me, I don't like mindless churn. This industry desperately needs to improve. It's running at about 5% (if that) of its real potential. But the constant fire drilling that comes with moving from one well-sold crappy technology to another well-sold crappy technology is really irritating, and it's part of why so many good programmers tend to move up into management.
11y ago

comrade1 11y 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).

smacktoward 11y 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.

vlunkr 11y 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.
- brlewis 11y 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.
  - talmand 11y ago
    I think the idea of reducing lines of code as a means of success can go too far. Sure, you can squeeze that block of code down a few dozens of lines of code, but then how hard is it to follow along behind you and deduce your intentions? You may be saving something today to just be needlessly spending it tomorrow.
    - mod 11y ago
      It's almost never taken too far, so generally speaking, this argument doesn't carry much weight. Also, at a few dozen lines per block, you could keep going a long way!
      - talmand 11y ago

atom-morgan 11y ago

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

michaelbuddy 11y ago
yes they are, all over the place.
- atom-morgan 11y ago
  My own experience on the job market is largely the opposite even if they say otherwise.
  - thekingshorses 11y ago
    I am hiring. http://interana.com/ http://interana.com/
    - atom-morgan 11y ago
      Unfortunately I just accepted a job offer about a week ago. Thank you though :)

savanaly 11y 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.

nahiluhmot 11y 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 11y 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 https://news.ycombinator.com/item?id=9871014
minitech 11y 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.
- akilism 11y 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?
  - minitech 11y ago
    The point of my comment was to say you don’t have to support old or obscure browsers specifically; just have proper content in your HTML and everyone will be satisfied without additional effort on your part.

Sakes 11y 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 11y 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".

cnp 11y 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 11y 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.
- Azkar 11y 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.
  - motional 11y ago
    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.

vlunkr 11y 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 11y ago

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

keithpeter 11y 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 11y 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 11y 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

alanh 11y 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 11y ago
This makes me wonder if there is a SEO bump/penalty associated with article dates.
- alanh 11y ago
  Doubtful – i think it's mostly oversight, but I’d be curious to hear from those perpetrating the trend!

at-fates-hands 11y 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 11y 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 11y 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.
minitech 11y ago
Yes, I remember when FrontPage achieved this very same revolution.
woah 11y 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 11y ago

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

kdamken 11y 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.

omouse 11y 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.

winnerscout 11y ago

Shut up, you faggot. Being a front-end dev is boring almost by definition. And the only time it isn't is when you can tell users witch shit clients to fuck off and go somewhere else. Faggot.

Killswitch 11y ago
Great way to get your point across and considered.
- winnerscout 11y ago
  Engage.

awkward 11y 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.

michaelbuddy 11y 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.
- awkward 11y 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 11y 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 11y 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 11y 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.

thebfed 11y ago
McDonalds and Coca Cola is very popular - is it good for you?

hlfcoding 11y 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.