Live data from Hacker News

The boring front-end developer

thebfed.com

51–60 of 149 posts

Re: The boring front-end developer

#51
post #49

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?

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.

Re: The boring front-end developer

#52
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 realize you were just making a specific observation about one situation, but it's worth noting that being an "older" developer (which at 15+ years experience would be late 30s) in no universe means that the developer doesn't know things. Indeed, the irony is that many shops full of junior FEDs found databases and stored procs so intimidating that we saw the rise of things like MongoDB. Even if it completely sabotag…

There were definitely "older" devs that wanted to do those things, but they didn't have the 15 years of tenure to be able to make those decisions. I should rephrase to say that if your devs don't want to learn new things, they probably aren't in the right field.

Re: The boring front-end developer

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

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.

Re: The boring front-end developer

#54
post #25
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…

"This is the technology industry, we don't have time for new technology!"

The industry that still argues about which text editor from the 1970s is the best tool to code in has a problem with rapid paradigm shifts?

I'm shocked.

Re: The boring front-end developer

#55

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.

Agreed. One example would be that using named variables, particularly set with "default" values, makes white-labelling applications much simpler.

Re: The boring front-end developer

#56
post #33
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.

Definitely an issue but it shouldn't prevent you from using some tools. For example, I've mostly stayed away from compile to JS languages except for ClojureScript (for personal project) and TypeScript because I see real value in both of them. TypeScript has been a massive boon to help with the largish client side app I work on professionally. Helps keeps the code base somewhat sane and easy to develop in.

CSS preprocessors have been similar, cutting down on duplication that leads to potential bugs is hugely useful.

Obviously taking small steps and sticking to things as long as there is no major benefit from switching helps. No reason to jump from Angular to React or whatever is new if it's fulfilling your needs.

Re: The boring front-end developer

#57
post #31
post #26

Earlier quoted context omitted.

I watched a company almost go under(shrank to almost no employees) after exactly what you described. The BFEDs(including the CTO) refused to update their skills and the company tools/stack and the company was beaten out by competitors.

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 few tutorials doesn't count as training).

Re: The boring front-end developer

#58
post #7
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…

I agree with your first point. Pre-processors, especially in the CSS realm, are so intuitive that there should be negligible training overhead. I believe they should be used past a certain threshold. I disagree with your second point, however. Single page applications are good for pages with a high amount of short, repeated interactivity where concurrency and frequent status updates are prioritized. However, there ar…

>>> Single page applications are good for pages with a high amount of short, repeated interactivity where concurrency and frequent status updates are prioritized

That's what I understand by webapp. Web sites (such as reddit) should stay server based.

Re: The boring front-end developer

#59
Anyone who's ever actually written a website using vanilla CSS and then gotten to write a site with Sass knows that not using a preprocessor in this day and age is insane. It makes things 1000x easier to write and more importantly to maintain.

Writing vanilla CSS after using a preprocessor is torture.

Re: The boring front-end developer

#60
Boring front-end developers also aren't involved in the project planning or design process so they're low-status. Of course I expect them to follow the spec and do things the boring way, because that's what they're paid to do. New tech? That's a new risk, better find someone else who will do exactly what we ask and not try to "improve" things.

What I see from the frontend developer community with all these new frameworks and tools is a rebellion against project managers and clients and the whole agency model which makes creating websites the most bland process imaginable.

Every single thing listed in the article is more fun. Being boring is fine but you better be paying the dev either very little because you don't really value them, they're simply a machine for turning your ideas into code; or you pay them a lot because you know if you don't they'll leave and take their great ideas and work for a competitor or start consulting and stealing clients.

Post reply on HN