The boring front-end developer
thebfed.com
thebfed.com
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.
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.
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.
I'd say you also have a problem if one or two devs want to use a tech but aren't also willing to train the rest of the devs in them (passing around links to a few tutorials doesn't count as training).
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.
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.
When trying TypeScript and CoffeeScript I never ran into issues like that.
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.
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.
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.
I work for a large medical company in its platform department and for any third party package or framework we definitely consider if it is really worth adding it, or if we can do this ourselves. Sure, things like sass we take, as we do with grunt. But we have serious issues managing our resources (fte) and backlog items. Many teams, even within our company, all want a different new cool technique. They want angular so we made directives on our UI toolkit. Another suddenly used dojo so we made wrappers for that as well, next we had ember, backbone, and soon angular 2.0 no doubt. We test the angular directives with jasmine, the JQuery with QUnit, and have saltarelle in the party as well.
Next come the just out of beta frameworks as meteor, sure you can work with meteor and our REST api services but minor support is only officially added in 1.2 (not even out yet). O, less is much better than sass, give me less, no wait typescript! You are missing out if you don't use react! O, and nodejs and Mongodb not postgres! We hear it many times, as many as we have customers actually.
My point, there is a middle ground here. Teams have a limited amount of resources and you have to balance the supported techniques with actual functionality.
As always, choose the techniques that work for you, not what is trending (new) or well backed (old) just because. I guess big companies should be more boring than small entrepreneurs. Rather not have the aviation software of the plane I make my business trips woth run on beta frameworks.
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.
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?
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.
I'm shocked.
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.
(emphasis added)
That was bad. Normally I try not to have such typos, but it is Monday.
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.
Analyse critically and deliberately. Be conscious of decisions.
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.
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.
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.
Also, at a few dozen lines per block, you could keep going a long way!
To use a somewhat skewed analogy, imagine you want to tell directions to a foreigner.
One possible answer could be "Go 200 meters west, then go 100 meters east, then go 100 meters south".
The route that this answer describes is needlessly complex. The simpler route "Go 100 meters east, then go 100 meters south" will bring you to the same destination in less time.
You could try to further simplify you answer and just tell "Use the old road". But while that reads even shorter, you have not reduced the complexity of the actual route. It's just hidden behind an abstraction.
I'm speaking more about what happens when you go too far and someone else has to deal with it. Let's say the simplest, and still descriptive, directions are:
go down Main Street
turn left at Oak Street
turn right at Acorn Lane
fifth house on the left
go that way, left at Smith's, right at Taylor's, brick house
My version is snappier, though! Maybe my liberal arts degree wasn't such a waste after all :-D
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.
>>> 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.
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.)
That's what I understand by webapp. Web sites (such as reddit) should stay server based.
> 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.
— 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!
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.
There are a lot of advantages to them that need consideration too granted.
[0] http://prog21.dadgum.com/200.html [1] http://prog21.dadgum.com/p21.css
I feel like this is a joke or amusingly unintentional.
But when I say webapp I don't mean blogs or regular mostly static websites. I mean Web applications.
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.
Putting bits of AJAX into a web app doesn't make it SPA. Lets say you have a CRUD web application that is tax forms which end up being 5-10 "pages" printed. Then as a SPA you would have to load all the code to generate the 5-10 pages of forms, validation, logic, etc. onto a Single Page. This single page would be where everything is done, the URL would not change and the end user would have a seamless experience.
If the goal is interactivity and seamless operation to the end user, attempting to mimic a desktop app, there are multiple paths to achieving that goal. Limiting the design to a single page seems sort of contrived and a "do it because I can" type of approach, absent of user requirements - in my opinion.
There's HTML5 history API, lazy loading... Seriously, you describe SPAs in very simplistic terms that are just not true. Do you have any experience building them?
Google Maps is technically an "Ajax powered web app", but it's technically an SPA too as you never encounter a full page refresh.
That and it often has more to load than your traditional html/css page, which means a less pleasant experience on slower connections (mobile).
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.
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.
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.
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!)
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.
Yes, precisely. But you could conceivably call such a ball of mud "boring" because there's nothing cutting edge about it.
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
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.
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.
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
Yes.
Let me show you mine: http://intercoolerjs.org/
Not mature enough yet to be completely BFED, but that's the goal.
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.
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.
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.
Writing vanilla CSS after using a preprocessor is torture.
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.
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.
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".
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.
Other than that, +1, good read, will share.
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.
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.
I do miss the fast-web (you know, text and pictures)
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.
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.