The boring front-end developer • Hacker News Board

Re: The boring front-end developer

#91

Post by thebfed » Mon, Jul 13, 2015, 7:07 PM UTC

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…

This.

Re: The boring front-end developer

#92

Post by vilmosi » Mon, Jul 13, 2015, 7:07 PM UTC

mod wrote: post #80

vilmosi wrote: post #49

Earlier quoted context omitted.

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.

Sorry, didn't mean to sound like I was making a blanket statement. I agree there's a fine line between web app and website. No-one should take the decision of using an SPA lightly.

Re: The boring front-end developer

#93

Post by vilmosi » Mon, Jul 13, 2015, 7:08 PM UTC

mattbrewsbytes wrote: post #81

vilmosi wrote: post #49

Earlier quoted context omitted.

Honest question, what's wrong with SPA?

Given that the vast majority of end users are not techie - what value does SPA add to an end user of a web application?

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

Re: The boring front-end developer

#94

Post by thebfed » Mon, Jul 13, 2015, 7:09 PM UTC

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…

New != bad && New != good

Analyse critically and deliberately. Be conscious of decisions.

Re: The boring front-end developer

#95

Post by michaelbuddy » Mon, Jul 13, 2015, 7:09 PM UTC

atom-morgan wrote: post #15

This may all be true but at the end of the day a lot of companies aren't looking to hire a BFED.

yes they are, all over the place.

Re: The boring front-end developer

#96

Post by thebfed » Mon, Jul 13, 2015, 7:12 PM UTC

sanderjd wrote: post #23

vezzy-fnord wrote: post #17

Earlier quoted context omitted.

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

Re: The boring front-end developer

#97

Post by snarkyturtle » Mon, Jul 13, 2015, 7:12 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?

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 connections (mobile).

Re: The boring front-end developer

#98

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

Killswitch wrote: post #75

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.

Engage.

Re: The boring front-end developer

#99

Post by scelerat » Mon, Jul 13, 2015, 7:13 PM UTC

In my experience, any learning curve for the popular CSS preprocessors (SASS, LESS) is dwarfed by the maintenance and productivity gains. The only downside to them is that thoughtless use of them can lead to very bloated CSS builds. But onboarding? LESS and SASS, fundamentally, provide what CSS should have provided from day one: nestable rules/statements, macros, and variables.

Other than that, +1, good read, will share.

Re: The boring front-end developer

#100

Post by thebfed » Mon, Jul 13, 2015, 7:15 PM UTC

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.

I am saying,consider all the disadvantages too. If you still think it's beneficial after that, at least it's a conscious decision.