Hacker News Reader

Comment by tomjen3 | Hacker News Reader

Thats because CSS is not powerful enough, not helped that you can't use something like flexbox if you need to support old browsers but even the latest version of $YOUR_BROWSER does not have a way to say that I want a list element to layout its elements in one vertical column that is also centered vertically on the screen if it has fewer elements than there is space for on a screen, but having it split into additional columns and align all elements in all columns to the top if there are more elements than space on the screen. It is a fairly simple layout and I ended up having to do it in JS because flexbox only has a few standard modes for what to do when the content overflows and those don't effect the margins of the element.

CSS needs to be replaced with a more capable scripting language, or at least one based on constraints but until that happens we are stuck with javascript.

View on HN

> Thats because CSS is not powerful enough

This kind of objection is totally missing the point.

And this isn't an argument that CSS doesn't have painful limits (it does) or even about what constitutes "enough" (within its limits, CSS offers enough possibilities that your own ideas of what the app "should" be like may be as much as a limit as the problems of CSS are).

The power of CSS is largely orthogonal to the underlying issue.

Ideally, your web site/app is still usable even with every last stylesheet completely ignored. It should work with Lynx, or with entirely non-visual user agents (screenreaders, search bots, Siri etc).

CSS should enhance via layout and other presentation rules where that's possible.

JS should provide more convenient application behavior where that's possible.

Instead, we've slipped into a space where the browser (and, frequently enough, one browser) is simply considered The VM That Lived™, just another runtime target. And that's a sign of its growing power, and that power isn't a bad thing because there are in fact some applications that don't fit the hypermedia model well and the browser's ability to play the just another runtime role opens a space for them. But the rush to get into that space is considerably overdone and apparently executed without a lot of awareness of what's been lost in moving that way.

Except the vast, vast majority of people don't care and use a normal desktop browser with JS on

My mom just bought a new phone and asks why it's still too slow and clunky like her old one. I found out she likes to click Buzzfeed-esque links from Facebook and most of those sites slow the device to a crawl because of the massive amounts of Javascript running.

People care about the downstream effects, they don't know the how or why, but they care.

Indeed. I think it’s important for engineers working on any kind of end-user facing software to remember that a lot of people aren’t using cutting edge or even recent hardware. There’s lots of Core 2 Duo laptops and 3+ year old smartphones floating around in use out there and their users need to be able to use the websites and apps we make as much as the guy who buys new everything every year.

I think this is particularly easy to forget for those of us living in tech hubs where everyone is using almost-new Macbook Pros and iPhone 6Ss.

I've never seen that client devs test their apps on lower end devices.

In 2014 I bought a ~50$ Android while traveling Latin America. I didn't expect much more of the browsing experience than reading mostly text based articles. But I didn't even get that. Literally half the linked articles I clicked on hacker news led to sites which where close to or impossible to navigate because of JS shenanigans and the assumption of an least a 4G internet connection.

It is especially annoying if one claims to target a world audience, but expects them to have a +500$ phones and vast data subscriptions.

The market fixes this, though. If your websites don't load on a low-end Android over 3G, you won't attract the sort of audience that uses that setup. Conversely, if you know what a large portion of your audience uses specs like that, you'll go through great lengths to ensure your sites are performant and usable.

It seems that most 'western' sites have decided focus on people with desktops or +500$ phones and vast data subscriptions.

In your example, most of the time the "market" won't fix that though, because there's no money to be made in servicing the users with "cheap" phones.

So it's really a Western web and not an open web. You've proven exactly what everyone on here is saying: there's so much focus on marketing and audiences that many users get completely shafted. That's sad to see given that the web is often heralded as something that gives under privileged people access, and the ability to share, to powerful and useful information.

In some places, $500 is about a half-year salary from which one has to live and feed their family. Nobody in their right mind would waste it on an electronic toy.

If my users care about and/or use Lynx that I will support it. Until then, it's just a feature that doesn't have the ROI to invest in.

Sure, sometimes you have to make tradeoffs for what you have time to invest in.

But this isn't really about supporting the world's Lynx users specifically. There's a reason I put a whole class of non-mainstream UAs in there (and in particular Siri, given how likely it is that entirely non-visual UAs are to become more mainstream at some point, perhaps soon, on top of the awareness that intermediary UAs like GoogleBot are of course ubiquitous and clearly important). And which UAs you try to support has a chicken and egg effect on which UAs get employed as intermediaries in accessing your site/app... and therefore which UAs you think you see using it. Usage follows accessibility perhaps even more surely than accomodation follows demand.

If that weren't enough, the decision to do the things that would mean that your site is usable in Lynx is not just a feature -- it's also a technical decision. And like other technical decisions (database, language, library, application architecture, idioms and patterns you use, and data serialization/interchange format... which is actually part of what this decision actually is), it matters to how well your product performs and how tractable it is to develop and maintain, as well as how widely it can be consumed.

If you're having to make cold hard decisions about ROI for features, chances are decent that you're better off for thinking about whether it works in Lynx and why, even if not one single user visits with that specific UA.

Fair enough in a way, but on the other hand.. will that be like JPEG2000, which browsers might support when websites use it, which might be when browsers support it?

Or put differently, how would someone who can't use or even see your thing become your user?

When I was a beginner I also tried to design all kinds of fancy, flexible and auto-adjusting stuff. With years I came to the understanding that most of it is just unnecessary and wouldn't diminish the user experience in any way if you didn't do it the fancy way and instead went with a simpler route.

CSS like any technology has its limits. In reality it is often good because it forces you to rethink what you're doing and reconsider whether you really need it. If we had a technology with unlimited capabilities, a lot of developers would be lost there forever and wouldn't be able to accomplish the larger goal completely lost in pursuing all the secondary details they could possibly imagine.

Most of the places I see javascript being used for layout are not doing complex things that can only be done in javascript. At the very least, there should be a non-javascript fallback so the content is visible and somewhat layed out.

All mediums have limitations.

CSS is good enough. It's overdesigning that makes the web the crap it is today.

Reply on news.ycombinator.com