Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The boring front-end developer

thebfed.com

Post reply on HN
Print view View original

31–40 of 149 posts

Re: The boring front-end developer

#31

Post by Azkar »

hiou wrote: post #26
cnp wrote: post #24

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 li…

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.

Re: The boring front-end developer

#32

Post by EnderMB »

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.

Re: The boring front-end developer

#33

Post by copperx »

cnp wrote: post #24

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 li…

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

Re: The boring front-end developer

#34

Post by Wintamute »

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

Re: The boring front-end developer

#35

Post by losvedir »

vezzy-fnord wrote: post #17
vilmosi wrote: post #2

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…

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 e…

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

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

Re: The boring front-end developer

#36

Post by serve_yay »

carsongross wrote: post #8

“As a Lead JavaScript Engineer, I try to get my team to write as little JavaScript as possible.” Yes. Let me show you mine: http://intercoolerjs.org/ Not mature enough yet to be completely BFED, but that's the goal.

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

Re: The boring front-end developer

#37

Post by alanh »

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!)

Re: The boring front-end developer

#38

Post by serve_yay »

hiphipjorge wrote: post #13
serve_yay wrote: post #5

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 (…

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

Re: The boring front-end developer

#39

Post by JustSomeNobody »

j_baker wrote: post #10

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. Bein…

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.

Re: The boring front-end developer

#40

Post by DCoder »

nahiluhmot wrote: post #18

> 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 "borin…

> 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

Post reply on HN