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

131–140 of 149 posts

Re: The boring front-end developer

#131

Post by shalmanese »

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

Re: The boring front-end developer

#132

Post by rawTruthHurts »

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.

I couldn't help but read the article as "hype beats reliability, and that's the ways it should be"

Re: The boring front-end developer

#133

Post by woah »

alanh wrote: post #51
vilmosi wrote: post #49

Earlier quoted context omitted.

Honest question, what's wrong with SPA?

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.

Similar to how I hate all hamburgers because of those damn dry McDonald's buns.

Re: The boring front-end developer

#134

Post by woah »

snarkyturtle wrote: post #97
vilmosi wrote: post #49

Earlier quoted context omitted.

Honest question, what's wrong with SPA?

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

Not true if you use a decent framework.

Re: The boring front-end developer

#135

Post by woah »

michaelbuddy wrote: post #83
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…

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

You might be interested to learn of source maps.

Re: The boring front-end developer

#136

Post by thebfed »

JamesBarney wrote: post #126

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

McDonalds and Coca Cola is very popular - is it good for you?

Re: The boring front-end developer

#137

Post by woah »

jdsampayo wrote: post #127
carsongross wrote: post #73

Earlier quoted context omitted.

Hmmph, indeed. However, it is a much simpler conceptual model than doing it w/ javascript off in some jQuery onLoad function: web requests just hit URLs like they always have, download HTML content like they always have and swap it into a rectangle, like they always have. It's just that the rectangle doesn't necessarily have to be the entire screen like it always has. The behavior of a given bit of HTML is fairly loc…

I think you will like Angular.

I think that OP likely knows angular and dislikes it.

Re: The boring front-end developer

#138

Post by woah »

curiousjorge wrote: post #46

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

I've never seen a wysiwyg tool that can cope with hand modifications to its generated source code. This would probably require strong AI.

Re: The boring front-end developer

#139

Post by talmand »

xg15 wrote: post #128
talmand wrote: post #70

Earlier quoted context omitted.

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

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.

Re: The boring front-end developer

#140

Post by talmand »

mod wrote: post #74
talmand wrote: post #70

Earlier quoted context omitted.

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.

It's almost never taken too far, so generally speaking, this argument doesn't carry much weight. Also, at a few dozen lines per block, you could keep going a long way!

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.
Post reply on HN