Earlier quoted context omitted.
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)
The boring front-end developer
111–120 of 149 posts
Re: The boring front-end developer
#112Earlier quoted context omitted.
> 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…
All of your points are good ones, but just to clarify: 1) While there are already new approaches to CSS via Webpack and CSS modules which in a way completely invalidate the term 'necessary', I've worked on some apps at said company that literally required CSS preprocessors. It would have been an organizational nightmare otherwise, considering the size and the scope of some of the asks. 2) Build tools encapsulate NPM,…
I work for a large medical company in its platform department and for any third party package or framework we definitely consider if it is really worth adding it, or if we can do this ourselves. Sure, things like sass we take, as we do with grunt. But we have serious issues managing our resources (fte) and backlog items. Many teams, even within our company, all want a different new cool technique. They want angular so we made directives on our UI toolkit. Another suddenly used dojo so we made wrappers for that as well, next we had ember, backbone, and soon angular 2.0 no doubt. We test the angular directives with jasmine, the JQuery with QUnit, and have saltarelle in the party as well.
Next come the just out of beta frameworks as meteor, sure you can work with meteor and our REST api services but minor support is only officially added in 1.2 (not even out yet). O, less is much better than sass, give me less, no wait typescript! You are missing out if you don't use react! O, and nodejs and Mongodb not postgres! We hear it many times, as many as we have customers actually.
My point, there is a middle ground here. Teams have a limited amount of resources and you have to balance the supported techniques with actual functionality.
As always, choose the techniques that work for you, not what is trending (new) or well backed (old) just because. I guess big companies should be more boring than small entrepreneurs. Rather not have the aviation software of the plane I make my business trips woth run on beta frameworks.
Re: The boring front-end developer
#113I 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…
Put it this way: there are still great C99 programmers who make fast programs, are they useless only because they don't use C++14 with all bells and whistles?
Re: The boring front-end developer
#114reminds me of http://motherfuckingwebsite.com/ (NSFW language)
I do miss the fast-web (you know, text and pictures)
Re: The boring front-end developer
#115Earlier quoted context omitted.
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
#116First things first: This article presents a lovely sentiment — although any argument against CSS preprocessors is a losing one — and is a timely reminder to focus on the things that matter. However… When was this published? There’s no date anywhere on the page or even in its source code, but he mentions supporting "IE6 and below". This is actually no longer possible if “HTTPS” is a requirement, as the best version of…
This makes me wonder if there is a SEO bump/penalty associated with article dates.
Re: The boring front-end developer
#117Earlier quoted context omitted.
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.
Sounds like you are desperately reading something into the original article which just isn't there. The author is clearing saying consider all the disadvantages too. If you still think it's beneficial after that, at least it's a conscious decision. Your comment has a some major weaknesses and reading does a great job patching those holes.
— TFA
Read literally, the paragraph says “If there are any downsides, do not use preprocessors.” A more balanced approach of weighing upsides and downsides is not supported by the original text.
If the author wanted to say something different, he can and should have done so. I encourage him to change his call to action from “say no to preprocessors” to “be conscious of decisions.” It’s much more defensible and realistic!