Hacker News Reader

Comment by paganel | Hacker News Reader

Not the OP, but I expect the web to be a thing where documents (i.e. mainly text) don't have any issues rendering on my 5-year old phone or on my 8-year laptop (both of which work very well, still, and which I don't plan to replace anytime soon).

The recent web practices (I'm talking mostly of the last 2-3 years, since more and more people have started copying Twitter with its launch of its "every website needs to be a JS-app" thingie) have practically destroyed how most of the websites are displayed by the 2 devices I own. Sites like Hacker News or Wikipedia, which still work perfectly fine, are very far and few between. I sincerely deplore this.

View on HN

A web limited to textual content is a pretty quaint and uninspiring vision, IMO.

The web started that way because static documents are relatively easy to represent, but the future (and present, for that matter) is rich experiences that can be distributed in the same way.

But there are many steps left to get there, so either buckle up and help build that future, or get used to an ever-shrinking ecosystem of the purely textual Web.

I'm personally very excited by the convergence of mobile and web development, PWAs, improved functionality for layouts, self-hosted app architectures (like Tent and Sandstorm, language-agnostic runtime via Web Assembly, better serving performance via HTTP/2, low level multimedia APIs, encapsulation of rich UX via Web Components, and so on and so on.

Sure, it's bewildering right now, but in the future, this will all be knit together in a cohesive way.

Do you want to bet on that last one?

Sure, but in the meantime the web is a much less accessible place for screen readers, underpowered mobile devices, and those without good internet connections

> Sure, it's bewildering right now, but in the future, this will all be knit together in a cohesive way.

Could have said those same words literally a decade ago when we were all struggling to figure out all this Rails and MVC stuff and how automated ORMs worked above MySQL. Seven or eight paradigm shifts later, we're all still confused and I see no cohesive knitting.

My opinion happens to differ. Textual content is incredibly rich and is likely a target for all content in the future. Consider, we are literally training models to accurately caption things today.

Why? Because language is a hell of an abstraction. More, it is approachable and can often be bounded. Consider, I am not even remotely skilled in art. However, I can adequately describe, for me, a picture by saying who is in it and the event. Try doing the same without language. Often "quaint and uninspiring textual" language.

Do I opine for the what we had in the 90s? Not necessarily. But I do grow weary of folks reinventing frameworks that merely further complicate the very abstractions that they created and now require these frameworks.

> Sure, it's bewildering right now, but in the future, this will all be knit together in a cohesive way.

You'll get over that optimism when 20 years passes and it's a worse mess than it is now; that's what going to happen.

It was was has worked for almost 5 thousand years, so I am going to go ahead and say it is not quaint, its not uninspiring, and when you say "in the future it will all be knit together in a cohesive way" I laugh heartily. It never has been, and it wont be.

You could say the same thing about flying cars. A car with four wheels is a pretty quaint and uninspiring vision, IMO. However it happens to be infinitely more practical.

The fact is that 99% of what's done on the web is (mainly textual) document management/display. Facebook (the website responsible for React!) is 99% document display.

The truth is that "rich experiences" are mostly made by enhancing the basic experience of reading rich documents. If you want an inspiring vision of a document-centered future, look at IndieWeb.org. And/or roca-style.org. It's a vision of how the web can be knit together into a cohesive whole based on URLs, rather than segmented into a bunch of unaddressable silos.

About self-hosted app architectures, Cloudron is really good in terms of stability. Just got a newsletter from them that they are hitting 1.0 soon.

And I would love if my 2001 Honda Accord was compatible with Tesla's autopilot, but I understand it is not a realistic expectation.

I'm not sure why you'd expect the web to be a. Mostly text and b. able to render easily on obsolete devices.

The web is becoming a robust application delivery platform. That is so, so awesome. Most people do not want to be stuck with shitty looking, text only websites. Moving the platform forwards necessitates that it will use more resources. Increased resources availability and consumption over time is fairly consistent across most aspects consumer computing.

They may be robust but the user experience still sucks. JS heavy web sites are unresponsive and turn my 3 year old MBP into a vacuum cleaner. Facebook is the best example. I can barely load the web site without the fans spinning. Firefox can't handle it at all. It is unusable for me.

That is crazy. I use Facebook on a 5 year old MBP with no problems. I have Ad Block Pro and U-Block, but even without them, my computer can handle Facebook just fine.

ublock origin is the only adblocker you need. Adblock Plus does the same thing but is less efficient and lets some ads through by default, and ublock is abandoned.

Don't run two ad blockers, they will just use more resources for no benefit.

Something is wrong with your MBP.

It isn't just him. Facebook slowed for whatever reason on my PC too in the last half a year.

4.5 GHz 4670k, 16Gb of tight timings ram.

Might be more Firefox than your macbook or the web. I've noticed (while developing an extension) that Firefox feels noticeably more sluggish than Chrome. Safari somehow feels even faster than Chrome, but I'm too tied to the extension ecosystem of Chrome to switch.

I have the same experience with Firefox on OSX. I noticed that it isn't an issue with the dev version of Firefox with multiprocess turned on.

Firefox is definitely partly to blame. Chrome does work better and Safari is probably the best of the lot.

Safari is definitely faster than Chrome on Mac.

It also uses significantly less power.

Alas I dream for the day when Safari adopts WebExtensions

I'm using Chrome but I tend to agree. A particularly painful area of Facebook is Buy/Sell pages. It slows to a crawl if you scroll through too many listings. Even on my 6 core X99 system.

Ubuntu on chromebook user reporting. I cant complain much on the latest chrome even with my 2 gigs of ram and much less powerful processor.

This experience is not unique to the web, from what I've seen. Apps that aren't well made can easily drop frames on a 3 year old iPhone.

The point isn't that the web should be mostly text, but that it shouldn't comprise of layers and layers of unnecessary fiddle-faddle that doesn't add anything useful to the end-user's experience.

If you can convey what your trying to convey with a JS-less (or even just JS-lite) 2-page website, then don't build a monolithic, scroll-hijacking, background-parallaxing fireworks show of a website, tied together with the most tenuous of Javascript libraries.

I'm all for the web as an application delivery platform, but not every website, or application, needs so much bulk.

That's not a problem with the ecosystem though. That's a problem with bad developers. The same is true for any technology and programming language.

> The web is becoming a robust application delivery platform.

This was our mistake. I don't want garbage shoved in my face. I want to read. And that's it.

> Increased resources availability and consumption over time is fairly consistent across most aspects consumer computing.

Worth remembering this is the case for people interested in tech. The local library still runs Vista on a 10yo system. My parents will use Android 2.x until the phone does not turn on anymore. Bandwidth updates don't apply to many people living outside of towns. Etc. It's been a long time since we've reached a point where an average person shouldn't need more bandwidth and power to look for information online.

And BTW, you can have beautiful text-only websites. These 2 properties are not related.

Amen! React might be the best tool for building hybrid mobile or even cross platform electron apps, but the truth is, it suck balls for web development.

Bundling the entire website inside a single js file, that needs to be re-downloaded everytime you add a div or change a single css class is stupid, sorry.

Your website doesn't need to be pure text. It can be beautiful, modern and responsive. And it doesn't need much js for that.

The world has become mobile first, not js-centric. Pushing spa everywhere is just wrong.

React is great for web development (using Next.js) based on my recent experience.

Citing only one side of any architectural trade-offs isn't particularly interesting either. The other side is that we can now easily build sites using Universal JS (serverside-rendered combined with SPA).

Delivering a website with seemingly instantaneous repaints even on flaky internet connections is just a superior end-user experience.

Just click through the primary nav of a Universal JS site vs an old-school one, and it feels like we've been putting up with the equivalent of the old 300 ms tap delay, but for all websites and website links.

Not engineering away that latency penalty will tend towards foolish for website properties that want to remain competitive.

Users will become increasingly accustomed to very responsive sites and the latency penalty that is currently normalised will become more glaring and unacceptable.

What has been your experience on server side rendering ? We are very concerned about SEO,etc - have you seen any impact of using Next.js on SEO performance,etc

We have a number of Next sites in development at the moment, but none in production (soon!).

SEO shouldn't be a problem, especially as the initial page is serverside rendered.

The only slight complexity is in returning sitemap.xml I believe, which requires a little bit more configuration currently. If you search the Github repo for 'SEO' you should find some tickets (open and / or closed) that discuss this.

I'm with you, but it's just part of the growing pains. The web is successful because it's easy to layer businesses on top of each other... I can have a Tumblr with a Shopify backend and Google Adwords on top. Apps are walled gardens so they can only enforce one business model at a time. That can make things nice and tidy, but it walls you out of the messy, compositional business models of the web.

Because business models are composed on the web, it's just harder to settle on unified design standards. It takes time for everyone to agree on a separation of responsibilities on the page. This is compounded by the sheer newness of the business models. My webcomic about fancy cheeses has a segment marketing a line of tractors now to industrial buyers at a conference in Wisconsin this week? OK. That's an opportunity I probably wouldn't have had selling Java apps.

Well what's unique about HN and Wikipedia? They're largely non-monezited. If Buzzfeed can make more money off of a flashy website it's hard to argue with.

I don't think it's either/or. You can make a "flashy" (in the sense of Buzzfeed) without it being burdened by huge amounts of js. Likewise, monetized sites are still frequently not like Wikipedia or HN.

HN doesn't do much, but Wikipedia does a decent amount of stuff with JS on their website despite people taking it as an example of "the web as documents"

meanwhile, I don't know how FB or Twitter are nice user experiences when you operate on a "paginate 20 tweets at a time" philosophy.

Ten years ago MapQuest was state of the art, and you'd click "next tile" over and over to traverse a map. Then Google Maps showed up with its voodoo ajax and infinite scroll and ushered in the modern web app era. Sure, some folks overdo it, but I'm not going back.

That is a vision that is incompatible with the reality of computing from the past 10 years.

I would love HN to provide an easy way to see where the reply thread to this first comment ends. Some js might enable that. Basic html/css - I think no.

It's that [-] button next to the username above each comment. It collapses all the cascading comments. It is enabled via JS. If you disable JS, then it disappears.

Thanks, I didn't see it

I suspect you could hack a similar collapsing thread UI together with styled radio buttons and no JS, if you really wanted to prove a point.

But I seldom hear people saying the old web pages can't be shown on today's browser.

Reply on news.ycombinator.com