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

101–110 of 149 posts

Re: The boring front-end developer

#101

Post by michaelbuddy »

vdaniuk wrote: post #28
savanaly wrote: post #16

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

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

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

Re: The boring front-end developer

#102

Post by jasonlotito »

alanh wrote: post #53
jasonlotito wrote: post #12

Earlier quoted context omitted.

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

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.

Re: The boring front-end developer

#103

Post by cnp »

wwweston wrote: post #62
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…

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

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.

Re: The boring front-end developer

#104

Post by [deleted] »

smacktoward wrote: post #14

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

[deleted]

Re: The boring front-end developer

#105

Post by cnp »

omouse wrote: post #57
Azkar wrote: post #31

Earlier quoted context omitted.

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

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.

Re: The boring front-end developer

#106

Post by krapp »

pc86 wrote: post #69
Azkar wrote: post #31

Earlier quoted context omitted.

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.

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've seen PHP projects that require NPM to compile the css and js...

Re: The boring front-end developer

#107

Post by cnp »

copperx wrote: post #33
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.

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.

Re: The boring front-end developer

#109

Post by vlunkr »

talmand wrote: post #70
brlewis wrote: post #61

Earlier quoted context omitted.

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.

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.

Re: The boring front-end developer

#110

Post by marcosdumay »

akilism wrote: post #77
smacktoward wrote: post #14

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

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

Yes, ok. Some lines are more of a liability than others.
Post reply on HN