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.
> someone not ready to handle the incredible momentum of the industry
The momentum of the industry certainly presents some credibility questions, but I'm not as sure as you are if they're about anyone who isn't content with a treadmill as their professional lot.
Here's big quote of the article: "The BFED will develop a site based on the context of the problem and provide a solution accordingly."
A BFED isn't necessarily someone who's reflexively resistant. Skeptical, maybe, because another way of describing the "momentum" of the industry would be that it's filled with tools whose adoption is often carried along by their own adoption/social proof as much as their unique merits as solutions (and that's the good case, we're not talking about the problem of hyped products whose merits might be deeply in question).
And if CSS preprocessors are an example of industry momentum presenting necessity... well, I've worked on lots of projects with LESS and SASS and lots without. They can be nice, but there's no way I'd draw them inside a circle of necessity. There's a set primary problems they can address relating to keeping source keystrokes down and keeping values defined in single places. They tend to produce some of their own problems (emitted code size and source mapping). There are other solutions a good team that knows CSS and a good text-editor well can use -- good enough I'd be willing to bet on such a team's ability to keep up with (or surpass) than a team that reflexively uses LESS or SASS and considers their problems solved because that's How We Do Things Now™.
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.
All of your points are good ones, but just to clarify:
1) While there are already new approaches to CSS via Webpack and CSS modules which in a way completely invalidate the term 'necessary', I've worked on some apps at said company that literally required CSS preprocessors. It would have been an organizational nightmare otherwise, considering the size and the scope of some of the asks.
2) Build tools encapsulate NPM, just like Make encapsulates bash (in a way). Coordinating a large team using shell scripts or cramming everything into package.json is never fun, though I do prefer NPM for smaller, more focused projects where each dev is on the same skill level.
The point is: these tools have their purpose, there is a ton of documentation around them, and even if they are not the best tools for the job it is the frontend developer's role to research and evaluate their merit rather than dismissing them outright.
As with most things in life things are not that black and white. You are referring to the BFED extremists whilst the article is maybe referring too much to the cool frontend extremist.
I work for a large medical company in its platform department and for any third party package or framework we definitely consider if it is really worth adding it, or if we can do this ourselves. Sure, things like sass we take, as we do with grunt. But we have serious issues managing our resources (fte) and backlog items. Many teams, even within our company, all want a different new cool technique. They want angular so we made directives on our UI toolkit. Another suddenly used dojo so we made wrappers for that as well, next we had ember, backbone, and soon angular 2.0 no doubt. We test the angular directives with jasmine, the JQuery with QUnit, and have saltarelle in the party as well.
Next come the just out of beta frameworks as meteor, sure you can work with meteor and our REST api services but minor support is only officially added in 1.2 (not even out yet). O, less is much better than sass, give me less, no wait typescript! You are missing out if you don't use react! O, and nodejs and Mongodb not postgres! We hear it many times, as many as we have customers actually.
My point, there is a middle ground here. Teams have a limited amount of resources and you have to balance the supported techniques with actual functionality.
As always, choose the techniques that work for you, not what is trending (new) or well backed (old) just because. I guess big companies should be more boring than small entrepreneurs. Rather not have the aviation software of the plane I make my business trips woth run on beta frameworks.
There is a great KISS principle. When you can effectively develop a website using only vanilla CSS & HTML and a bit of JS, why use some overhyped fancy tools like grunt, gulp, bower, less, sass, yeoman, etc.? I can open vim or any other code editor on any PC and start coding web pages right away, without spending hours on configuring complex toolchains, writing build scripts and so on. If web pages could be done that simple oldschool way 5 years ago, couldn't they be done the same way today?
Put it this way: there are still great C99 programmers who make fast programs, are they useless only because they don't use C++14 with all bells and whistles?
> There are too many good ideas being born right now to risk falling into rigid patterns of thinking.
The problem is that there are too many ideas out there, period. It's almost impossible to separate the wheat from the chaff. See: JavaScript libraries.
Definitely an issue but it shouldn't prevent you from using some tools. For example, I've mostly stayed away from compile to JS languages except for ClojureScript (for personal project) and TypeScript because I see real value in both of them. TypeScript has been a massive boon to help with the largish client side app I work on professionally. Helps keeps the code base somewhat sane and easy to develop in.
CSS preprocessors have been similar, cutting down on duplication that leads to potential bugs is hugely useful.
Obviously taking small steps and sticking to things as long as there is no major benefit from switching helps. No reason to jump from Angular to React or whatever is new if it's fulfilling your needs.
I wish I was using TypeScript right now; we're using babel for ES6 transpiling and I've found a situation where a particular importing of a module doesn't work correctly. It appears correctly when I run it through the eslint tool and babel/webpack don't seem to complain when compiling, but in the browser it doesn't work.
When trying TypeScript and CoffeeScript I never ran into issues like that.
A pragmatic solution to this problem is to follow certain key developers closely on Github and Twitter, the ones most aligned with the patterns and issues you or your company are addressing. The repos they star and the tweets they forward give you a sort of inside look into where the industry is going; this inspires confidence in decision making.
I watched a company almost go under(shrank to almost no employees) after exactly what you described. The BFEDs(including the CTO) refused to update their skills and the company tools/stack and the company was beaten out by competitors.
I worked at an organization that didn't let us use stored procedures or OOP because the older devs couldn't understand them (it was a Navy contractor, so there were guys that had been there 15+ years).
If you decide not to use a technology because the developers can't or are unwilling to learn them, you've got bigger problems than technology choices.
I'm at yet another place where every one does their own thing and once you get past 2 devs this quickly becomes an issue. But heaven forbid you want to set aside time for training and making sure everyone is on the same page with regards to skill and methods.
I'd say you also have a problem if one or two devs want to use a tech but aren't also willing to train the rest of the devs in them (passing around links to a few tutorials doesn't count as training).
Almost all of my "successes" in bringing people over to more modern practices centered around actual training. Meaning, creating sample apps and arguing effectively with upper management and the devs that I worked with daily.
For about 4 months I worked at a place where the senior dev's first question regarding any technology would be whether or not it could be done in VB6 (this was circa 2009 or so). If it could, he'd make the decision that it just had to be done in VB6 because that's what the shop was using at the time.
I realize you were just making a specific observation about one situation, but it's worth noting that being an "older" developer (which at 15+ years experience would be late 30s) in no universe means that the developer doesn't know things.
Indeed, the irony is that many shops full of junior FEDs found databases and stored procs so intimidating that we saw the rise of things like MongoDB. Even if it completely sabotages any medium or long term plan, if all you know is JavaScript and have very naive notions about the uses of data, seems great.
There were definitely "older" devs that wanted to do those things, but they didn't have the 15 years of tenure to be able to make those decisions. I should rephrase to say that if your devs don't want to learn new things, they probably aren't in the right field.
All front-end devs should be able to switch to that BFED mode though, especially on pages that don't _need_ to be fancy. This helps with cross-browser compatibility and pagespeed. You could still be fancy, but only as a necessity and even then it should be layered on the BFED-side.
The problem with devs nowadays is they skip the BFED and just jump into SPA's without knowing how to make a well-working website without tons and tons of sass/js.
I think this is just one of those things that every developer needs a healthy balance of. BFED qualities are required to ship code on time with minimal defects. Using the latest-and-greatest technology helps drive growth as a developer, but introduces risk.
For me it's a matter of identifying new technology that is valuable to invest my time into learning, and knowing when it's appropriate to learn the new technology.
I think the ideal is a "tick tock" strategy where you're either allowed to innovate on tooling or innovate on product but never both at the same time. Reserve interesting tooling experiments for small, well defined, non user facing systems so that your team becomes familiar with the pros/cons, then apply it to large scale core functionality once you've gained the experience.
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.
I didn't read that in the article. Being a technologist means know when NOT to use a technology as much as knowing when to use it. There're way too many developers who read links from HN and try and push the javascript framework of the weak on everyone at their job without fully comprehending the consequences of their decision. That's not being a technologits, that's being stupid.
> There're way too many developers who read links from HN and try and push the javascript framework of the weak on everyone at their job without fully comprehending the consequences of their decision.
One good question to ask yourself when evaluating a framework is this:
If the project/company dies out tomorrow, and we're tied to this thing, can we take it in-house and pick up maintenance?
If the answer to that is no, not even long enough to migrate to something else, then boy, you'd better be damn sure that the team that develops it isn't going to go away or lose interest. Hence my skepticism with many, many Javascript "framework of the week" projects. There's just far too many out there that have died out after a year or two for me to blithely accept whatever the new hotness is.
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.
Reinventing the wheel is only a part of the problem. The other is that the wheel is spinning in the same place. And I even suspect that the cart is no longer there.
> “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.
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.
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.
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.
I think it makes more sense if you see lines as an indicator for the thing you'll really want to minimize, which is the complexity of the model and/or instructions you describe in the lines.
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 not against reducing complexity, I don't think that's necessarily going too far.
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
versus:
go that way, left at Smith's, right at Taylor's, brick house
The second is an example of refactoring to reduce line count but actually increases complexity to someone not familiar with the area.
This is true, I've seen one-liners in ruby that will make your eyes bleed. As I've matured as a developer I've felt the need to write less lines to code, but also to be very clear and explicit. I think there's an appropriate balance somewhere.
Yes, reduced spending in any area can go too far. There's such a thing as justifiable spending. Calling it spending merely illustrates that it isn't automatically a good thing.
The fact that it's almost never taken too far is a good example that it actually does carry a great deal of weight, it's just one of those things that people respect.
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.
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.
Ironically in the context of the original article, it's precisely when you're trying to support IE 5+ or 6+ (or even more modest goals) that less/sass is really valuable, since you can generate chunks of CSS values with all the browser prefixes/hacky workarounds/etc, and still be able to think about things at a higher level.
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.
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.
I'm sort of coming around to this perspective as well. Ever since I read this article[0] on more of a APL/J/K style to CSS (the author's blog's CSS looks like this[2]), I've noodled with the idea of doing straight CSS again, in this pretty condensed format. It's kind of shocking at first, but does have its own charm.
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.)
>>> 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.
Yes, hugely ironic. “Listen, these things are never black-and-white. [pause in which audience expects a call for careful consideration, case-by-case.] They are always white.”
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.
If people disable JS or if it fails for whatever reason, you'll be left with an unusable site. If fonts don't load or if css doesn't load, at least you still have html and you could read what's on the screen. With JS you won't even be able to navigate to pages since it all gets handled with js.
That and it often has more to load than your traditional html/css page, which means a less pleasant experience on slower connections (mobile).
Google Maps is famous as a pioneering use of AJAX, not as an SPA. Whether it is or is not an SPA at present is largely immaterial. There are many ways to create interactive experiences without full-page reloads, and going full SPA is just one route.
AJAX and the ability to manipulate the DOM has been around for about a decade or so, AJAX came out of Microsoft I believe.
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.
>>> This single page would be where everything is done, the URL would not change
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.
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.
Sorry, didn't mean to sound like I was making a blanket statement. I agree there's a fine line between web app and website. No-one should take the decision of using an SPA lightly.
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.
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.
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.
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.
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.
> 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!
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.
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!)
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.
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.
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.
"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.
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.
> 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.
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.
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.
> 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
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.
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.
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.
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.
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.
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.
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.
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".
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
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.
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.
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.
>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.
This "manifesto" doesn't even try to consider tradeoffs. There is no analysis of stakeholder preferences or path-dependent UX/UI evolution or personal projects for fun and learning. It doesn't consider neither business requirements nor developer satisfaction.
However, the article is quite good at hipster shaming, so it gets upvoted to HN front page. A classic example of link bait tailored for its audience.
It's telling that your comment with point by point discussion of BFED propositions is at the very bottom, btw.
>He/she will not just use [insert buzz word here] to improve his/her chances of finding another job based on the current technology fad in order to increase their day rate.
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).
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).
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.
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.