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 boring front-end developer
51–60 of 149 posts
Re: The boring front-end developer
#52Earlier 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…
Re: The boring front-end developer
#53Good 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…
Re: The boring front-end developer
#54Blah. 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!"
I'm shocked.
Re: The boring front-end developer
#55Earlier 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.
Re: The boring front-end developer
#56I 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.
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
#57Earlier 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'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
#58Good 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…
That's what I understand by webapp. Web sites (such as reddit) should stay server based.
Re: The boring front-end developer
#59Writing vanilla CSS after using a preprocessor is torture.
Re: The boring front-end developer
#60What 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.