6 ms·
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, CoffeeScri
by vilmosi 11y ago
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 to preprocessors.
Really? You will ignore the many many advantages of pre-processors because it will be harder to train new people? Come on...
>>> Furthermore, the BFED realises that Single Page Applications cause severe problems and that by avoiding them and leaning on the server appropriately provides a better experience and reach.
That's a bit one sided. There's a time and place for SPAs, you can't just dismiss it entirely. Every web app today should be an SPA.
Edit: I should clarify that by webapp I don't mean website. There seems to be some confusion.
- xwkd 11y agoI 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 are plenty of applications that I use where I prefer to have a workflow built on discrete states (pages). They typically perform better in terms of rendering time and latency, both in terms of request and user action. (Just compare reddit's mobile beta to their previous mobile site. I still type in /.compact because I can't stand the new SPA.)
- vilmosi 11y ago>>> 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.
- jasonlotito 11y agoWith 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 already well established, and most debugging will happen within the browser. The tooling already exists to make this easy. To me, harder doesn't mean you won't have to learn something new, but it's actually more difficult. And that entirely depends on how you have things setup and what tooling you have. This does mean that if I invite LESC and want to use that instead of LESS, it will be harder to use precisely because the tooling isn't present.
- alanh 11y agoSounds 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.
- thebfed 11y agoI am saying,consider all the disadvantages too. If you still think it's beneficial after that, at least it's a conscious decision.
- jasonlotito 11y agoSounds 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.
- alanh 11y ago> Will it be harder to onboard developers? Will debugging code be more difficult? If the answer to any [sic] of these questions is yes then the BFED will say no to preprocessors. — 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!
- vezzy-fnord 11y agoControversial 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 example on the front page. The compiled output is simpler than the source you're writing. I find having some code duplication to be an acceptable trade-off for turning a basic declarative configuration language into a chimera DSL that must be incorporated into the build process. The more a configuration language strays away from being declarative, the less desirable this becomes.
- sanderjd 11y agoI 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.
- robinson7d 11y agoAgreed. One example would be that using named variables, particularly set with "default" values, makes white-labelling applications much simpler.
- thebfed 11y agoIt's not the only downside to consider. http://adamsilver.io/articles/the-disadvantages-of-css-preprocessors/ http://adamsilver.io/articles/the-disadvantages-of-css-prepr... There are a lot of advantages to them that need consideration too granted.
- sanderjd 11y agoCertainly, 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.
- BadassFractal 11y ago> > > 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.
- vilmosi 11y agoHonest question, what's wrong with SPA?
- alanh 11y agoThe 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.
- mod 11y agoNothing'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.
- vilmosi 11y ago
- fuzzywalrus 11y agoThis should phrased about how much you lean on preprocessors. Sass is more more intelligible than regular CSS in many circumstances unless you're trying write everything as programmatically as possible. Its easily to write a For loop that spits out a grid but may make look like greek to a junior dev. CSS preprocessors are unique, with LESS and Sass, you can write straight CSS and use its wonderful concatenation through imports, or just its nesting or perhaps simple variables for colors. There's so much benefit that I can't imagine not using them.
- michaelbuddy 11y agopeople act like once you get the team on board it will all start rolling, EXCEPT that there are a lot of projects where people come and go, people are temp, permanent and everything in between, changing constantly. Of course there's documenting right? Except you document and do this fantastic job training but when it's all set and done, technology has moved on when the project wraps and there's already something better that can't coexist with the method you used. Preprocessors also have disadvantages, not just training. Every time you abstract something, then abstract it again you are risking that what comes out could be problematic and harder to fix. think about this. in the end, the browser is displaying based on the final CSS. You inspect the final css. If you're trying to fix something, you have to discover it, then work backwards to it's source. Inspect tools show you what's there and what you have to edit. But it takes yet another set of steps and complexity to work backwards to your css before it was processed. make sense? So tech moves on and new complexity and longer problem solving procedures are introduced. Yay. No wonder there's an attraction to being boring. To rework a quote from bruce lee for this. The guy who practices one kick a thousand times is much more formidable than the guy who practices a thousand different kicks one time.
- woah 11y agoYou might be interested to learn of source maps.