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

121–130 of 149 posts

Re: The boring front-end developer

#121

Post by awkward »

michaelbuddy wrote: post #86
awkward wrote: post #76

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…

Yeahhh, you've not written a very good summary of what he wrote. But I hope it felt good to get a word in at least.

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.

Re: The boring front-end developer

#123

Post by vilmosi »

alanh wrote: post #115
vilmosi wrote: post #93

Earlier quoted context omitted.

Interactivity mostly. Imagine if Google Maps reloaded every time you zoom in or pick a location.

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.

Sorry, I'm a bit confused about the difference between an Ajax powered page vs an SPA

Re: The boring front-end developer

#124

Post by sanderjd »

thebfed wrote: post #96
sanderjd wrote: post #23

Earlier quoted context omitted.

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.

It's not the only downside to consider. http://adamsilver.io/articles/the-disadvantages-of-css-prepr... There are a lot of advantages to them that need consideration too granted.

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.

Re: The boring front-end developer

#125

Post by T-hawk »

smacktoward wrote: post #84
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 wasn't familiar with that Dijkstra quote, but yeah, it definitely gets at the same point I was getting at. My version is snappier, though! Maybe my liberal arts degree wasn't such a waste after all :-D

Same idea, attributed to Bill Gates: "Measuring software by lines of code is like measuring an airplane by weight."

Re: The boring front-end developer

#126

Post by JamesBarney »

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

Re: The boring front-end developer

#127

Post by jdsampayo »

carsongross wrote: post #73
serve_yay wrote: post #36

Earlier quoted context omitted.

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

I think you will like Angular.

Re: The boring front-end developer

#128

Post by xg15 »

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.

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.

Re: The boring front-end developer

#129

Post by atinoda-kestrel »

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.

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

Post reply on HN