5 ms·
All this has happened before, and will happen again. The reason should be that developers develop along as simple and as standardised a means as they can, so t
by detritus 6y ago
All this has happened before, and will happen again.
The reason should be that developers develop along as simple and as standardised a means as they can, so that what they're working on will be consumable by as many people now, and in future as they can be.
Sure, I'm of the 0.001% of people on the planet that could easily spend a half hour going through the console and working out why on Earth their content isn't displaying to me… but this is a .org (.uk) - their remit is to be open and to Do The Right Thing.
Almost 100% of their users are not the sort that should be expected to dissect their website to work out where they've gone wrong.
Again, this isn't anything complicated - it should just be HTML spat out. That's it. Nothing fancy.
- shadowgovt 6y agoIf there's one thing I've learned from 1+ decades of web development, it's that very few things aren't fancy. ;)
- detritus 6y agoCan you expand on this? I've been on/off making websites since '99 and I think have a moderate understanding of the landscapes past and present - I don't see what should be complicated in spitting out HTML onto a webpage. Sure, if you want to do fancy rendering shit after the matter, go crazy - but HTML should be just HTML, boring Hx tags and all. Just read this back - not challenging, but not wanting to waste HN mindspace on niceties, lol x
- shadowgovt 6y agoIt really depends on what you want to do, but to a first approximation (speaking very broadly and without much attention to detail)... Most things that would be considered "web apps" or even "web site development" require a lot of thought. The single biggest impedance mismatch is that HTML is still fundamentally a declarative language where the rendering agent is left as an exercise for the reader, while the things people want to do with it make more and more sense as imperative tasks. The declarative approach is a great idea---semantics separated from presentation! Pages load regardless of details of the device loading them!---but it's groaning under the strain of the rendering people want to do with it. The HTML abstraction is far divorced from the end result people want, and in that gap implementation nuances (and errors) creep in. Had a situation years ago where I was fighting multiple error reports from Firefox users because our UI was unusable. It was a scrolling list of data that used flexgrid to organize the columns (because we can't use <table> tags anymore; that's of course heresy ;) ). Something, somewhere changed in the Firefox implementation, and every scroll operation was triggering a reflow of the whole table (full recomputation of the height of every cell). Chrome? No problem at all. Chrome had some heuristic somewhere in the render engine that could tell the underlying HTML hadn't changed and was short-cutting the reflow calculation. One could claim it's our fault for using flex grid, but I mean... It's in the standard. Should work right. Not my team's fault Firefox's renderer has a bug that makes it supported but shitty (or that they don't have a testing benchmark shaped like our site to realize their performance had regressed). We chased that problem for half a week before product management pulled us off of pursuing it, on the calculation that it impacted <10% of our userbase and was way too inside-ball to keep burning company time on it (and in a sense, they were right; one major Firefox revision later, the bug was fixed and performance under Chrome and FF was comparable again).
- depressedpanda 6y agoWhat is 'flexgrid'? I'm quite sure it's not part of any standard.
- shadowgovt 6y agoSorry, I meant 'grid built using flexbox.' https://css-tricks.com/dont-overthink-flexbox-grids/ https://css-tricks.com/dont-overthink-flexbox-grids/
- deleted 6y ago[deleted]