But that's not actually what I'm rabbling about today. I won't get into the details of what syntax or implementation is better either.
They miss the point
Development tools are very helpful, but they also stint the ability to learn how to use a language more efficiently. Of course, what matters is to get things done, but in the long run it will make a big difference to those who put the work (or were inspired) to do it better.
For example: using variables in CSS makes sense when you think about re-using colors here and there. Could this be better addressed by using a separate stylesheet that deals with colors (and non-layout modifying rulesets)?
The point is that the inconsistency of content format makes a developer (or is it the other way around?) write a ton of rules to undo all the badly-inherited ones. The complexity of the current codebase makes it near impossible to even figure out what is reusable and how to use it —and frankly, most often things are not designed with reusability in mind: shocking, right?
So the problem about reducing code size is not about how big your code is. As we move into the future, the target market will increasingly be represented by higher bandwidth consumers, since those are the ones with the money to spend. —I understand there is a long tail and it is irrelevant here. As devices download faster and richer media is served, your CSS, HTML and JS will be puny compared to the number of images and HD videos that you're serving. Ever-increasing compression, bandwidth and client-side storage and caching will increase this trend, no matter at what rate. Given enough time, code size will be irrelevant.
What does matter is how maintainable your code is. Code size does become increasingly important but because there will be exponentially more time invested in fixing bugs and building new features as a direct result of the lines of code and people involved.
Another example: What about calculated dimensions? Isn't it a pain to keep track of what the paddings and width add up to?
You are missing the point
The future is bringing a diversity of devices: apps on phones, tablets, laptops, desktops and TVs. The more anyone is developing a pixel-perfect layout, the more it will look stupid on all other devices but yours. Adaptive layout requires thinking about how the content will flow and accommodate the available screen size and pixel density. Pixel-perfect layouts are perfect for making your work look like that spiffy mock, but it won't look so great on most devices by the end of next year, if not sooner.
This jewel from 2006, Switchy McLayout on ALA, explained it well a long, long, long, internet time ago (seriously, look at an internet meme timeline. That was the same year as ICHC!). But the point is not to talk about how great adaptive layout is.
The point
Tools that make you lazy are bad for you, but not as bad if you truly suck. Take the time to love and learn your trade or step aside.
Still here?
I'm glad. Let's build a better web. Check out these resources
@darkgoyle you're an artisan in a world that's rapidly automating. So long as profit drives the machine, efficiency will always trump variety for the masses.
ReplyDeleteClosure seems to be solving Google's problems pretty well but I've yet to work with it on any of the projects I've worked. But SASS is actually kinda boss. Not so much for all the extra magic interpolation stuff. But for a visually more coherent stylesheet. Treating styles as a multi-dimensional hash rather than a simple hash makes sense to me as a programmer and I'm still not sure why that hasn't been adopted in the css spec.
Nice write-up. And thanks for pointing me to the meme-timeline. Fond memories. :)
I just integrated GSS into Twitters development process. It has the features that I wanted (lint, variables, mixins, compression) without requiring massive rewrites (SASS ugly syntax) or adding a new dependency (LESS - NodeJS).
ReplyDeleteSo far so good, I like practical tools like this one over any "dreamy-does-it-all" solution