Writing Less Code
heydonworks.com
heydonworks.com
Another one of the things I really miss about the pre-JavaScript, pre-CSS, document-oriented (as opposed to the current experience-oriented) web is being able to make my browser window half or a third of my screen, and having documents be eminently readable. That was really, really nice. Try it now, though, and nothing really works correctly. Which is weird, because a third-width window on a laptop or desktop has roughly the same proportions as a phone in vertical layout.
Nope. That was true about a year ago, but not anymore. Facebook UI on a desktop is horrible. Try using it with 1024px wide screen - most apps/games aren't fully visible because they give 760px to the canvas and the rest of their UI is not responsive - so either the ad space on the right or the content (app/game) has to suffer.
http://i.imgur.com/K6ov1pv.png
What does it look like for you? You might want to let hn@ycombinator.com know.
Actually reading text is not the worst part (though if I want to zoom at all then stuff scrolls off the page, since it won't reflow on iOS when you zoom, and browsing becomes miserable then.) The worst part is trying to interact with the site on mobile. I basically just don't do it.
I use Firefox but it is the same with Safari.
of what? that you don't need a separate mobile site (or js) to show a most basic wall of text?
open up amazon.com or walmart.com and see how your justification holds up. certainly, there are simple layouts with sparse content that can be made responsive easily (blogs, image portfolios, etc) but this is a far cry from proof that a broad statement is at all applicable.
Most sites only need to show just that. And fail miserably at it.
>open up amazon.com or walmart.com and see how your justification holds up.
90% of sites are content based, not Amazon or Walmart. And even then could do with a much simpler layout.
> One that couldn't easily be changed, either, because everyone's clients relied on the exact structure of the markup for screen scraping.
This doesn't seem like that hard a problem. Presumably the robots all sent their own distinct UA strings (as scrapers only get written to imitate browser UA strings if you ban non-browser UA strings.) So why not just filter your logs to find all the known scrapers, serve anything with those exact UA strings "legacy" table-based responses, and serve everyone else the new layout?
Hackers they may be, web developers they are not.
Tons of sites assume a width of something that is obviously greater than 1080 pixels and break in awful ways.
Man what I remember was doing multiple columns using Tables in HTML which never worked in anything under a 700px resolution.
Case in point this beast: https://web.archive.org/web/20010503213654/http://www.techtv...
Now it's "HEY I SEE YOUR SCREEN ISN'T WIDE ENOUGH TO FIT TWO COLUMNS OF ADVERTISING ON THE SIDES. HAVE THE CELL PHONE LAYOUT WITH FULLSCREEN POPUPS INSTEAD!"
If you are a small operation that still makes your mobile web site usable, then power to you.
It really should be handled at the OS level for apps, or at the browser level for web sites: If I click anything on the screen, it should react as if I clicked on what was there 300ms ago, maybe 400 or 500ms or longer.
The fastest (typical) human reaction is around 300ms. If I'm clicking on something that appeared less than 300ms ago, then I'm NOT intending to click on it. Maybe the delay should be configurable, or maybe it learns the behavior for a particular user? An elderly person surfing the web might have a 1000ms propagation delay between deciding to click and clicking on a button or link. But my reflexes are closer to the 300ms point if not better on a good day.
No matter how fast a human is, if a button is covered by an ad 100-200ms before they click, there's no way to not click on it. And that's bad UI.
Even my (our?) favorite search engine, Duck Duck Go, is guilty of this: I will frequently accidentally click on the "WikiPedia summary" popup which has just replaced the actual top link that I wanted to be clicking on. Bad web duck!
From what I've read it's more like 200-250ms, but hardware lag does bring the end-to-end closer to 300ms.
300ms is a good lower limit, though, if you take into account complex video processing and standard brain activity when browsing; when hitting a button when you're browsing, your brain isn't wound up and ready to react as quickly as possible. Getting that extra fast reaction really requires short circuiting some of the mental processing you'd normally do. I'm pretty sure I'm remembering 300ms from the cognitive science/UI classes I took in college.
And don't forget the hardware lag in your own body. ;) The signal to click the button takes ~10ms to get from your brain to your fingers. When you think about things like sports where the accuracy of, say, releasing a ball when throwing it, needs to be in the 0.1ms range to hit your target, but your brain is actually giving the command 10ms before the ideal release time... Makes my brain hurt just contemplating how it works.
Pro tip: Don't think about this while trying to throw a ball accurately.
EDIT: While we're at it, there's a publishing group that displays all news articles as popovers over the main page. People accidentally click out of the articles and get dumped on the home page, containing expensive "site takeover" advertisements.
Can't remember the name of the company - they have a bunch of US-based local news sites.
I swear the the delay between appearing and sliding up is always timed and changed each day to cunningly coincide with my finger tapping on the area where the 'start' button used to be so that I almost always tap the 'pay us $$$' button instead !!!
It wasn't until 2008 when 800x600 was below 10% of users and I finally started using a 900 grid.
https://web.archive.org/web/20000603192652/http://www3.zdnet...?
Or at least, try as I might, I've yet to find a clear and comprehensive explanation of how to do it properly. So, despite thinking CSS Zen Garden is a work of beauty, for my own part I just throw bootstrap at it and get on with my life, and I'm not ashamed about it.
Then you do the real work and convert it to media queries that fit your design.
I suppose it's easy for me to punt because I'm not a front end developer. To be honest, though, CSS is such a bizarre layout system that I don't think I can blame the pros for doing it, either. Part of being a professional is finding the most profitable use for your time, and I doubt that most people will notice the difference.
Alternatively, you can use something like react with event triggering on window resize, and use the actual window size as part of your rendering... for example, I'll put the event to trigger my redux store so that state.window.size.height/width are set, I'll sometimes also do the window.scrollTop in the events as well.. this way I can use that in code for my components...
render(props) {
if (props.window.size.width < 600) return null;
if (props.window.size.width < 1024) return <div>...</div>;
...
}
[1] https://github.com/tracker1/md-datepicker/blob/master/_src/D...
If only there were some way to force every site to use those techniques. Electric shock, perhaps?
Stick a menu, some photos, a table, a form and item layout in there and you start hitting the pain points of web design.
Of course this is no excuse to not be able to make a perfectly responsive site with those hard parts as well - just people are lazy.
I'm rocking a 13" MacBook with the browser in full screen mode, so I suspect my screen's dimensions are well within the range of typical users. The fact that I encounter sites like this on a daily basis is an eternal source of wonder.
I do occasionally run across a site which uses fixed width divs and either won't squish down past 1280px, or gets all messed up because they plainly didn't test on narrow windows, but they're in the minority.
What do more experienced designers think of them? Handling spacing between elements is usually a pain (should I add margin on the top, or the bottom?), and font sizes proportional to the display width is IMO genius, so why aren't these declarations used more often?
EDIT: the article title is a little unfortunate, I thought it was about the modern Javascript ecosystem and that every tool has to have some kind of plugin system, modularity, extensibility, and require a ton of boilerplate to fit your 3-file website. Or that's what I expected, anyway.
For me, the single most useful technique I've discovered in the past few years has been "drop the 'C' in 'CSS'" and instead think in terms of modular components with virtually no cascading or selector nesting. E.g. BEM. Getting over the aesthetic ugliness of "class-itis" in my markup has freed me from a ton of agony trying to reason about why certain elements on the page are being styled a certain way.
I'm partial to rscss (http://rscss.io) although that's another "technique" that doesn't seem to be used a lot in the wild. Just makes sense to me.
One thing I'm not sure about though is the child selector. I often have intermediate layers between the root of my component and the elements. Wrappers and stuff to make certain positioning possible. This won't be possible with child selectors only.
> when it comes time to build sites with some visual and/or layout complexity I always wind up with so many exceptions to the rule
I've been looking for a LONG time for articles about consistent design and typography applied to UIs and boring CRUD apps. 99% of the article about vertical rhythm, spacing, typography and general design are about designing blogs and text-heavy sites.
I need something that teaches me how to design a functional, beautiful and user friendly reactor control dashboard.
In the meantime... with some discipline you can keep things self-contained just by using unique classes for each component (like what BEM and other similar naming conventions espouse). Could also look into CSS linters to keep you and your team honest.
I replied to the parent comment here - https://news.ycombinator.com/item?id=12308352. You might find it useful.
Yep, it renames them - https://github.com/vuejs/vueify#scoped-css
Makes things so easy that it feels like cheating.
If you write CSS for your personal blog and want to mass-apply styles to save time, go for it, but I think the majority of people who write CSS as a part of their daily work will find that this attitude creates more headaches than time savings.
My one concern is that it might get weird on mobile. Android apps, though maybe not mobile pages, have all kinds of awful problems with any font that isn't a convenient integer multiple of pixel size. I'm curious whether this renders gracefully.
Have used * + * before. It creates this huge dependence on the placement and ordering of your html you can't create psudo elements to pull off some style trick, there are often a bunch of exceptions when using it too that it kind of defeated the purpose of using it in the first place. Best to have a .class * + * in front of it to relegate it to a specific area.
The margin application though is very clever and the right way to go about it, even in complex designs you'll be able to apply this to most components (maybe not using the body selector though).
These aren't used more often because many developers aren't very familiar with the complete power that CSS has to offer, take BEM for example it completely eradicates the most powerful feature that CSS has to offer.
And yes, security and error checking are necessary. Anybody who says otherwise should be drawn, quartered, shot, and fired.
As much as I like this post, a framework sometimes has some value. If you're writing a true SPA, it'll only be loaded once, and something like React or Mithril is nice for a bit of structure. Mithril in particular, due to its small size, is handy.
I tried to figure out what ESR meant here and after a minute of Googling I'm guessing it's Eric S. Raymond[1]. Please consider not using uncommon acronyms on online forums, it obscures your meaning.
[1] http://www.catb.org/esr/writings/taoup/html/ch12s01.html
[1] https://www.jwz.org/about.html
JGC hasn't written any particularly well-known code.
On the flip side, we both took it in turn to forget GLS (aka The Great Quux), to say nothing of johnc.
<input type="checkbox" id="checkbox1" name="checkbox1">
<label for="checkbox1">My checkbox label</label>
<label><input type="checkbox" name="checkbox1"> My checkbox label</label>
Here are some selectors you can use with that setup:
input + label { ... }
input ~ label { ... }
input:checked + label { ... }
input:checked ~ label { ... }
By the way, using the visuallyhidden class is the ideal way of hiding a tabbable element like a checkbox while keeping it adjacent in the flow to its related elements. This method of hiding is especially kind to low vision users of your site who use tab to navigate your forms.
From an accessibility standpoint, having label-with-for is helpful to screen readers of varying quality out in the wild. label-with-for ensures the screen readers will never be mistaken about which label goes with which checkbox.
.visuallyhidden, input:checked, label-with-for, and the +, ~, and > combinators, plus WAI-ARIA attributes can be used to make visually appealing, yet accessible, widgets without JavaScript.
<label><input type="checkbox" name="cb"> <span>My checkbox label</span></label>
label input:checked + span { ... }
[EDIT:] It seems sibling comment had the same idea while I was testing this on the other tab.
One of the accessibility guidelines of the WCAG is that content in your markup MUST flow in the same direction as it is rendered on your page. This is recommended so that screen readers will read the page aurally in the same way as a sighted-user would read the page visually. If you follow that guideline, then placing your input tag before the associated label tag in the DOM usually makes sense because that is a common visual ordering for those elements.
The 'for' attribute in the label tag has semantic value that the span doesn't, you're just adding that span so that you can use the CSS combinators. If I squint, you're DRY, but once I unsquint I think YAGNI. :)
Seriously though, it really is a social good to strive to make your page content accessible both stylistically (for the low vision users, color blind users, etc.) and semantically (for the screen reader users).
An input inside a label has had an unambiguous meaning for decades. Why haven't screen readers caught up?
I believe the :checked pseudo-selector is only useful on radio and checkbox. It's just serendipitous that the common visual ordering matches the useful DOM element ordering for CSS styling in those cases.
I would expect label to come earlier in the DOM for other types of form elements so we could be compliant with the WCAG and we would still rely on the for attribute to link the two tags together for the screen readers.
Just my two cents; clearly I don't care as much about this stuff as you do. Good luck!
:checked is also relevant for <select>/<option> tags.
[0] https://www.w3.org/TR/WD-html40-970917/interact/forms.html#h...
Modern screen readers are really great and standards-friendly. There are even fully featured free/open source options. The problem really is disabled users stranded on old platforms.
It is very common for users with disabilities to not want to disclose their disabilities to websites. Very common to see low vision users use an independent magnifier tool rather than the browser zoom, for instance. Screen reader software is not detectable on the user's browser. So hoping to get a good count of users with disabilities visiting your site is going to be fraught with difficulties.
The kindest thing you can do from a web design standpoint for people with disabilities would be to read the WCAG, understand the issues and tradeoffs, and make tweaks to the way you form your markup and styles to conform, where you are able.
I learned about all this stuff while working on a public utility's website that got sued by a disabled persons' legal rights group who (legitimately) argued and won a case where they claimed the site was inaccessible to screen reader users. The site was totally atrocious, legacy Struts cruft, and we got to do a full overhaul of the UX, markup, and CSS for accessibility.
I expect more of these types of lawsuits in the future, so it could be useful career-wise to be aware of this stuff.
WCAG infos: https://www.w3.org/TR/WCAG20/
I've done web development for a little over 12 years now and the amount of times I've seen someone pull in a huge framework, fonts, tons of libraries just to make a simple page is astounding. I once worked at a job where they abused ASP.Net to such a degree that they were delivering a page to the user of over 70MB (about 60MB of that was only ViewState!!!) and while the application had its complex pieces that was only on a homepage that showed a very, very crude dashboard with only the functionality to re-order boxes. Boxes!
Frameworks have their place. Libraries have their place. They're helpful. But you don't need to bring them in every single time you write a web site or application. That code eventually has to be downloaded and viewed by a user and if you can do it with as few dependencies as possible your users will subconsciously thank you.
I'm a back end developer. I learned JS in the context of Node. The amount of time it would take me to learn some useful CSS would decimate my ability to get something out the door compared to just pulling in bootstrap. It's often the case that there simply isn't enough to be done to necessitate hiring someone correctly suited for the job. Additionally, whenever I leave my company and they find someone to replace me, there's a strong chance that person knows bootstrap. There is a balance to be had with user joy and developer joy.
What's with the myth that CSS is hard? It's perhaps the easiest thing about web dev.
Learn flexbox, learn units of measurements, learn specificity, learn media-queries - 5 hours max (a week of lunch at the desk) playing around in JSfiddle, and you're most of the way there.
Bootstrap is fine but pulling in a framework that has 656 classes seems a little unnecessary most of the time.
Perhaps I've been made cynical by my experience with several other sites, but I was half-expecting to have to enable JS from a bunch of other domains just to get the content to render correctly, if at all, and still be blocking a bunch of ads and social media plugins atop that. There would be a disappointing irony were that the case.
But no, the whole site loads quickly and correctly with no intervention on my part. The only thing uMatrix is detecting _to_ block is Google Analytics, and blocking it is having no impact upon the content on the page.
I wish this were the rule, not the exception.
Hey designers: 'See, you don't want a programmer touching front end. You have to have creative control. Else they'll make reddit and hacker news UX.'
http://image-store.slidesharecdn.com/3f5416bc-c975-4915-a9d1...
I'm also intending to build a scraper simply so I can determine what my highest voted comments of all time are.
Perhaps with Web protocols, things are ... entangled in inconvenient ways ( for, you know, ... reasons ) such that the formation of two tribes is a solution.
I don't generally build Web things. When I do build a GUI, I intentionally give it an old style, because I'm really a systems programmer ( eek, a third tribe! ) and this invites someone else to express the resulting inevitable disgust in a replacement. But meanwhile, there's an interface for it.
For the love of god, please use some common sense when repeating mantras like "write less code." I've seen this used to justify all sorts of ridiculous shit, like dropping basic security measures (write less code! YAGNI! Why would someone try SQL injection/XSS against our site anyway?!?).
If I propose something and your thought-terminating cliche response is some form of "YAGNI," I hate you.
This has been my experience too. While the concept has value, I find most people that throw the term around do so as a justification for not thinking much.
To armchair psychologize a bit, I think that enthusiastically embracing an acronym which, whatever its conceptual merits, is just so lame-sounding correlates negatively with taste, and taste correlates, albeit imperfectly, with programming skill, especially the skill of writing readable code.
It's a short, easily pronounced English word whose meaning is a nice metaphorical fit for the concept expressed by the acronym.
You can argue acronyms in general are lame, but I'm not taking that hard line.
As I say in a cousin comment, good taste is just 3rd order laziness. You're doing less by avoiding future trouble.
To armchair psychologize a bit, I think that enthusiastically embracing an acronym which, whatever its conceptual merits, is just so lame-sounding correlates negatively with taste
Wouldn't you prioritize conceptual taste over aesthetic taste? YAGNI probably sounds goofy because it was created in the late 90's. It was part of the original Extreme Programming formula. The concept is as solid as such concepts get, however.
Sure, my point was they're related (usually).
> The concept is as solid as such concepts get, however.
It's useful in many cases, yes. Solid? No. It requires far too much attention to context, and experience, to apply it wisely all the time. That is to say, YAGNI is invoked in defense of bad decisions as often as it is of good ones. That was the grandparent's point.
Sounds a little like you generally stop at the aesthetic level. The map isn't the territory, and the signals aren't the actual internal mental state of the person. Since you say "usually," how have you been accumulating data about this relationship?
It's useful in many cases, yes. Solid? No. It requires far too much attention to context, and experience, to apply it wisely all the time.
Hmmm. You should be making exactly this sort of decision all the time. The major task of a developer, as I see it after doing this for 36 years, is to pay a lot of attention to context and apply what you've learned by experience wisely. Erring on the side of caution and waiting until there's evidence you need something isn't a bad 1st order heuristic. I would label people who consistently stop at the 1st order heuristic and go no farther as "shallow."
No, it doesn't sound like that at all. You've just decided to read it that way and make an ad-hominem argument instead of engaging with the statement itself.
> Hmmm. You should be making exactly this sort of decision all the time. The major task of a developer, as I see it after doing this for 36 years, is to pay a lot of attention to context and apply what you've learned by experience wisely. Erring on the side of caution and waiting until there's evidence you need something isn't a bad 1st order heuristic. I would label people who consistently stop at the 1st order heuristic and go no farther as "shallow."
I agree with everything you said, and have not said anything that contradicts it.
It's a good heuristic. And it's only that. And lots of people apply it poorly.
Well, no. You've said a lot of things in this thread that seem to indicate that a 1st order heuristic only has value if it can be used in place of cognition. If there are more than 2 possible answers, a 1st order heuristic that was correct 40% of the time could still have value.
And lots of people apply it poorly.
Applying it properly is taking it as, "We need more evidence to justify the cost/benefit." That's conceptually more precise, though it manages to sound even more awkward than YAGNI. But from what you've been saying, it seems like "YAGNI" is simply the end of discussion.
To be fair the author said write less _damn_ code.
Regular code, however, is fine.[1]
[1] Even better if your code is blessed.
Good taste is just a form of 3rd order laziness.
Great line! Saved in my quotes file.
Of course, only if you actually don't need it.
IME, the YAGNI principle is most useful with new-ish developers who've been taught certain patterns but haven't grasped the motivation for them and so can't judge when the overhead is worth it. In Java-land we'd be talking about the old every-class-must-implement-an-interface-and-come-from-a-factory clichés. It's not that it's a bad pattern, just that until you have multiple implementations and/or a need for DI it probably isn't worth the source bloat.
In that situation I think YAGNI is exactly the right objection, and I'm not sure what would take its place if it became widely Considered Harmful.
It's incredibly mind-numbing when it's being used to justify laziness and short-sightedness. Worse, it's not exactly a misuse of the phrase, as per the original XP article:
> Always implement things when you actually need them
Security is, as an example, one of those things where you'd face a disaster if you just implemented it when you actually needed it (i.e. when an attack occurred).
YAGNI is incredibly short-sighted in situations where rectifying the situation later will be an absolute nightmare (or just impossible). An ounce of prevention is worth a pound of cure, and all that.
[EDIT:] wow!
∄ code c : c > ε (where the empty word ε represents no code and a>b means that code a is better than code b)
Should make the play on words clearer, while also ruining it.
Three days after giving birth, 92 percent of the new mothers said they were having problems breast-feeding.
No, I don't want to hear you ramble on with the discourse of someone who thinks they are hilarious and likes the sound of their own voice too much. Just get to the point. /rant
<label>
<input type="checkbox" ... />
<span>Label Text</span>
</label>
...
For fonts, have a base size for `html, body` then use `rem` everywhere else.
It sounds like they are practicing the oldest profession
For example, when Flickr transitioned from a single-column to the current row-by-row clusterfuck, it became much harder to quickly find a particular image in someone's photostream.
Check out http://tachyons.io.
It has a scale for widths, margins, paddings and fontsizes.
Specify pl1 to pl7 and get padding-left from 0.25 to 16rem.
w1 to w5 for width of 1,2,4,8,16rem.
f1 to f6 and f-headline for a proven typographic scale that makes sense.
Everything is relative to the fontsize. No more magic values!
Plus the scale are powers of two so integers only and everything always adds up. No more off-by-1-pixel errors!
And there's even a port for react-native: http://github.com/fab1an/react-native-style-tachyons.
My take: one single column that the rendering visible area can figure out how to render. No hidden agenda. only and just information worth reading: learning, discussing, agreeing ir disagreeing.
(my first papers were from a teletext or a stencil or a typewriter they were of the information I wish for to read today at least 3-4 times a week. instead of 3-4 days go by for one.)
Bring back the pure unadulterated brain output.
Not when you're writing consumable services IMO. The less you write in building a REST API, for example, the _more_ opportunity there is for someone to break it. It's important to catch exceptions, write detailed models, write tests for fail/success cases etc...
It's a good principle (optimizing for less code), but not always.
That said, I have been using Bootstrap, which is heavy weight, but I like how my mobile web sites also look nice on the desktop and on tablets.
You should consider updating your WP Supercache or maybe just WP? to have a max-age longer > 3. Maybe you have a use case I am unaware of that effectively voids browser cache though.
For example the @Cleanup annotation.
Based on my non-comprehensive empirical study, that describes about 3% of hero images in the wild. That is, unless almost all products are deeply related to fashionable twenty-somethings using a laptop in a coffeehouse surrounded by cute stationery with interesting organic textures.
Is that what Macbooks are called these days?
Dammit munificent, get it right.
I like this coder!
Glad to see its more or less a consensus.
Then since Dreamweaver was garbage people decided that any WYSIWYG HTML-editor is guaranteed to be terrible and nobody ever tried again.
Someone is trying: "https://www.tinymce.com". No idea how good this is.
Dreamweaver is still the best WYSIWYG HTML editor, and it's still garbage at it.
"Never EVER copy/paste code. Refactor!"
https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
It has a scale for widths, margins, paddings and fontsizes.
Specify pl1 to pl7 and get padding-left from 0.25 to 16rem.
w1 to w5 for width of 1,2,4,8,16rem.
f1 to f6 and f-headline for a proven typographic scale that makes sense.
Everything is relative to the fontsize. No more magic values!
Plus the scale are powers of two so integers only and everything always adds up. No more off-by-1-pixel errors!
And there's even a port for react-native: http://github.com/fab1an/react-native-style-tachyons.