The boring front-end developer • Hacker News Board

Re: The boring front-end developer

#71

Post by 0xdeadbeefbabe » Mon, Jul 13, 2015, 6:35 PM UTC

JustSomeNobody wrote: post #39

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.

> and push the javascript framework of the weak

(emphasis added)

Re: The boring front-end developer

#72

Post by winnerscout » Mon, Jul 13, 2015, 6:36 PM UTC

Shut up, you faggot. Being a front-end dev is boring almost by definition. And the only time it isn't is when you can tell users witch shit clients to fuck off and go somewhere else. Faggot.

Re: The boring front-end developer

#73

Post by carsongross » Mon, Jul 13, 2015, 6:41 PM UTC

serve_yay wrote: post #36

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.

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

Re: The boring front-end developer

#74

Post by mod » Mon, Jul 13, 2015, 6:41 PM UTC

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.

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!

Re: The boring front-end developer

#75

Post by Killswitch » Mon, Jul 13, 2015, 6:42 PM UTC

winnerscout wrote: post #72

Shut up, you faggot. Being a front-end dev is boring almost by definition. And the only time it isn't is when you can tell users witch shit clients to fuck off and go somewhere else. Faggot.

Great way to get your point across and considered.

Re: The boring front-end developer

#76

Post by awkward » Mon, Jul 13, 2015, 6:43 PM UTC

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.

Re: The boring front-end developer

#77

Post by akilism » Mon, Jul 13, 2015, 6:45 PM UTC

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.

Re: The boring front-end developer

#78

Post by snarkyturtle » Mon, Jul 13, 2015, 6:46 PM UTC

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…

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.

Re: The boring front-end developer

#79

Post by akilism » Mon, Jul 13, 2015, 6:47 PM UTC

minitech wrote: post #63

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…

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.

Am I supposed to worry about IE6 when Microsoft doesn't? Can we draw the line at supporting things when their creators give up on them?

Re: The boring front-end developer

#80

Post by mod » Mon, Jul 13, 2015, 6:49 PM UTC

vilmosi wrote: post #49

BadassFractal wrote: post #19

Earlier quoted context omitted.

> > > There's a time and place for SPAs, you can't just dismiss it entirely. Every web app today should be an SPA. I feel like this is a joke or amusingly unintentional.

Honest question, what's wrong with SPA?

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.