[HN Gopher] The Web I Want (2018)
___________________________________________________________________
The Web I Want (2018)
Author : rafamaddd
Score : 61 points
Date : 2023-05-14 19:57 UTC (3 hours ago)
(HTM) web link (quii.dev)
(TXT) w3m dump (quii.dev)
| dang wrote:
| Discussed (a bit) at the time:
|
| _The Web I want_ - https://news.ycombinator.com/item?id=17816494
| - Aug 2018 (2 comments)
| TacticalCoder wrote:
| I have no solution for the web turning to complete shit _but_ I
| do have a solution for the "laptop on fire" / fans going crazy
| and my solution even helps the planet a tiny little bit.
|
| I do simply throttle my entire CPU when I'm on a virtual dekstop
| / workspace where there's a "surf the Web" browser opened (as
| opposed to, say, a workspace where I have a browser I use to test
| stuff in dev).
|
| It's all automated from my window manager: everytime I switch
| workspace the maximum CPU speed allowed is modified. I go to
| workspace 3, where my editor/IDE is, the CPU governor is set to
| "ondemand" ( _i.e._ the CPU can boost to 5.5 Ghz if it wants to).
| I go to other workspaces: the CPU governor is set to
| "powersave".
|
| It's brutally efficient. No more noisy fans because this and that
| websites are busy executing oh-so-important JavaScript code to
| track me.
|
| I don't bother modifying the max TDP of the GPU when I switch
| workspaces but I could (the reason I don't bother is that I'm
| using fanless GPUs in my two main machines).
|
| It just works.
|
| In the past I used to put CPU and RAM quota on processes/group
| running browsers but I find it much easier to just modify the
| CPU's power settings upon switching workspaces.
|
| It's trivial to do and there's really not much websites can do
| about it. They can basically suck it.
| fernly wrote:
| Case in point: http://68k.news/
| waboremo wrote:
| Only 1 mention of ads, and it's quickly brushed aside.
|
| Not as if using an adblocker immediately speeds up your web
| browsing or anything.
| DanielBMarkham wrote:
| Interesting thought experiment: aside from streaming videos, how
| much bandwidth do you actually need a day? That's updates, posts,
| tweets, news articles, and so forth.
|
| Not very much. It's not unusual to load a humongous site with
| tons of libraries to get one or two sentences of information you
| wanted, usually after the obligatory 3 paragraphs of bullshit AI
| text.
|
| My guess is that the actual information, in text, that you
| consume in various forms is extremely small. The ratio keeps
| getting worse and worse for the consumer.
| elco13 wrote:
| Agreed. Everyone nowadays wants to make their media in non-text
| forms like videos, when I would honestly prefer that your
| tutorial on how to bake cookies could just be in text form. We
| shouldn't have to load megabytes of JavaScript to "watch" a
| recipe online that could easily be done in writing.
| amelius wrote:
| This website says it better:
|
| https://motherfuckingwebsite.com/
| jakebasile wrote:
| I agree with this in principle and my own personal site is
| basically "just" a website, but the lack of _any_ styling to
| make things look just a little nicer always turned me off to
| this rant in particular. I am not good with CSS, but there's
| plenty of essentially drop-in CSS files out there that would
| take a text heavy barebones site like this from "basically a
| text file open in notepad" readability to something a normal
| person would actually want to read. It's so easy that there's
| really no excuse not to grab one and drop it in.
|
| edit: looks like I'm not the only one, there's a collection of
| <adjective>motherfuckingwebsite URLs floating around:
| https://github.com/lyoshenka/awesome-motherfucking-website
| amelius wrote:
| You could take the original motherfuckingwebsite's approach
| and allow the user to set a default CSS in their browser.
|
| This is basically how programmers use terminals. But somehow
| we thought that "users" want things differently ...
| bbbbzzz1 wrote:
| > Most websites are about delivering and exploring content. HTML
| is amazing for this, and you don't need JavaScript.
|
| Most commercial websites want analytics on how users browse and
| click on the website. So this point goes out the window.
| porcoda wrote:
| This is why the web (and computing in general) is the way it is
| today: everything prioritizes what businesses and developers
| want, and the desires/needs of the people who actually use it
| are considered afterthoughts and annoying inconveniences. :-(
| 542458 wrote:
| Also, I'm not sure that most websites are about delivering and
| exploring content. I think most websites are fundamentally
| about either delivering ads or selling you stuff. "Delivering
| ads" usually requires JavaScript, and "Selling stuff" can be
| done without a bunch of JavaScript, but the experience wouldn't
| be great.
|
| I don't dispute the thesis of "web pages today are often way
| too bloated", but I think it's important to be realistic about
| the problem space. The author calls out JavaScript driven
| carousels as an example of unnecessary bloat... yet the
| Amazon.com home page features one such carousel prominently. I
| doubt they would put it there without A/B testing the heck out
| of it. To be fair, Amazon is way smarter about it than most in
| how the page paints and is interactive very quickly, but my
| point is that it seems to me that most web users want something
| more than what JavaScript-less HTML and CSS can provide.
| CelticBard wrote:
| [flagged]
| andrewfong wrote:
| At this point, I feel like the party best equipped to reduce
| JavaScript bloat are the web browsers themselves.
|
| There's the obvious stuff, like simply blocking third party
| tracking JS.
|
| There's some small quality of life bits -- a non-trivial number
| of websites load JS to make prettier UI elements (like a nicer
| date picker) because the defaults are so ugly (on desktop at
| least -- mobile tends to be better). If browsers shippednicer
| default UI elements, folks would be be less inclined to write
| their own using JS.
|
| And then there's larger fundamental changes to the API
| themselves. If HTML6 included virtual DOMs or reactive
| primitives, that might reduce the inclination towards framework
| bloat.
| josephg wrote:
| > If HTML6 included virtual DOMs or reactive primitives, that
| might reduce the inclination towards framework bloat.
|
| Please no virtual DOM. A virtual Dom is pure overhead compared
| to how svelte or solid renders.
|
| But I'd be very curious about what proper browser integration
| would look like for reactive frameworks if you have an instinct
| for what better apis could look like?
| account-5 wrote:
| I've ublock installed with the advanced user setting ticked,
| JavaScript disabled by default. The amount of blogs that load
| nothing until JavaScript is enabled is ridiculous. And some sites
| simply don't run unless you enable 60 odd 3rd party JS scripts to
| run.
|
| Either way my experience of the web is fast and generally fine
| and any site that wants me to jump through hoops in ublock to run
| I don't bother with and I'm happier for it.
| __MatrixMan__ wrote:
| I think the next step is a plugin which runs the scummy JS,
| captures the DOM, and makes it available in some kind of P2P
| fashion so that others can just load it without running the JS.
| I'd put $5/month in an account to pay people to cache the web
| for me, $10 if they'd clean up the ads while they were at it.
| phkahler wrote:
| Frameworks are a form of lock-in, or a moat. Once you build
| something complex, the cost of your customer changing supplier is
| higher. You build that local pub website using big fancy stuff
| and they can't hire a WordPress person to do some simple updates.
| Never mind a plain HTML and CSS person.
|
| Sure, it's easier for whomever built it, but it's also harder for
| anyone else. You are using these tools and frameworks to serve
| yourself, not your customers.
|
| It's like using VB to customize MS office, or the total lock-in
| you face with SAP customizations. But in those cases it maybe
| brings some value. With web sites you're really building
| complexity without improving presentation or adding value.
| h43z wrote:
| Server Side Rendering is making a big comeback these days. I
| think we will see a big drop in transported bytes over the wire.
| quechimba wrote:
| I've been working on a React-inspired framework in Ruby [1,2].
| It only requires a few kilobytes of JavaScript, and only
| includes the relevant stylesheets for each page. Works pretty
| well and I guess I'm in a rural area (about 90 minutes down the
| river from Iquitos, Peru) on a 4G connection.
|
| I recently did another experiment [3] where each static DOM
| tree becomes a custom element, which also reduces the amount of
| data that needs to be transferred.
|
| I should probably make a Show HN post soon...
|
| 1. https://github.com/mayu-live/framework
|
| 2. https://mayu.live/
|
| 3. https://github.com/aalin/rdom
| 1vuio0pswjnm7 wrote:
| Let's have an example of website that could be improved by
| reducing use of Javascript. According to the so-called "tech"
| company employees on HN, it's all theoretical. The web is
| actually just fine.
|
| There's no problem. It's all blog post author imagination. Turn
| off the ad blocker.
|
| The web advertising industry is on the side of web users. Web
| users are getting everything they want, and more!
| Karrot_Kream wrote:
| This post itself offers nothing concrete to criticize; I guess
| you're just supposed to read it and vibe? Why did the site load
| 35 MB of content, what are those chat channel requests, etc
| etc.
|
| Look https://news.ycombinator.com/item?id=35852516 made the
| front page 5 days ago and is another blog post saying the same
| thing. The problem is, without actually surveying a bunch of
| sites and looking at what they load and why they load it we
| won't know where the bloat comes from. I'm not convinced that
| JS is the issue because a simple JSON payload response (sans
| TCP overhead and connection establishment) is a matter of
| bytes.
| erulabs wrote:
| The web I want has fun, interesting, healthy applications that
| make the world a better place to live in.
|
| Who cares what technology is used to build it. That's an
| implementation detail for us builders.
|
| Pragmatism > Idealism
| enos_feedler wrote:
| I'm not sure why that commenter who observed these claims get
| surfaced all the time yet nothing has changed, got
| flagged/downvoted. I was about to say the same thing. I'll add a
| genuine question here in hopes to spur some discussion:
|
| It is clear the web is turning into trash or is already there,
| depending on your view. What genuine efforts have been made to
| rebuild the web without starting on the web/browser? We could
| just start over and not allow the same things that made the web
| today turn to to shit.
| thombles wrote:
| > What genuine efforts have been made to rebuild the web
| without starting on the web/browser? We could just start over
| and not allow the same things that made the web today turn to
| to shit.
|
| What you're describing sounds like Gemini, which has been
| fairly successful in its own niche.
| https://gemini.circumlunar.space/
| paxys wrote:
| > It is clear the web is turning into trash or is already there
|
| Back in the "good old days" people keep mentioning there were
| maybe some single digit million people online. Today there are
| ~5 billion. So by what measure are things clearly worse? And
| for whom?
| manuelmoreale wrote:
| I just want to point out that more people using X doesn't
| necessarily make X better. More people using the web today
| it's just that, more people using it.
|
| As for what measure, things are probably worse from a
| privacy/tracking stand point and also from a user
| centralization stand point. At least in my opinion.
| noahtallen wrote:
| I think there are a lot of huge misconceptions about modern web
| dev in posts like these. The part of the internet that's trash
| is pretty much anything related to ad tech (and therefore
| tracking). But this is also what funds basically the entire
| web. Probably the best thing about the web is how accessible it
| is -- you can use it for free if you can find an internet
| connection. Plus, its inherit flexibility makes it a very
| powerful platform. These together make it incredibly popular,
| but also make it ripe for abuse, and make advertisements a
| requirement as long as people don't want to pay.
|
| But the takeaway from these posts seems to be "JavaScript is
| bad." This completely misses the point -- anyone with, say, a
| recipe site strewn with ads and newsletter popups is doing so
| for the money. If people were willing to pay for recipes
| online, maybe things would be different. But the core economic
| model of most websites is to use ads to let it be free. You
| can't change the UX around these types of sites without
| changing the economics. (Though some, like Brave, have tried.)
|
| Media companies can and do build minimal feeds (lite.cnn.com),
| but they'd never allow that to be the default since it doesn't
| make any money.
|
| IMO, these conversations need to talk less about the tech
| (which isn't super relevant -- you can make plain HTML shitty
| too with enough ads), and more about the economics of the
| internet.
|
| And if we're talking about niche hobby and personal sites,
| people just use whatever tool they want because they're
| experimenting and having fun. Being fast and efficient isn't
| always the goal for someone playing around in their free time.
| waboremo wrote:
| That's a great summary: economics of the internet.
|
| Until we start discussing that, we're just going round and
| round with micro-optimizations while the elephant in the room
| continues swinging around.
| paxys wrote:
| > Most websites are about delivering and exploring content. HTML
| is amazing for this, and you don't need JavaScript.
|
| This is the fundamental misconception that most "get off my lawn"
| people like the author have, which leads to a variant of this
| exact post getting voted to the top here every single day.
|
| The web is not about delivering big blobs of text and images. It
| may have been at one point, but we are far beyond that. Instead:
|
| 1. The web is now first and foremost an _application_ delivery
| platform. The web browser is an OS. The website is an executable
| program.
|
| 2. The web is not a niche hobby for nerds like it was "back in
| the day", but a $15+ trillion global business.
|
| The sooner you can accept both of these, the more sense
| everything will make. What you did as an early adopter of the
| internet 30 years ago is irrelevant. You are not getting that
| time back. The party is long over, and everything is only going
| to get more commercial as time goes on.
| ChrisMarshallNY wrote:
| This is true.
|
| But applications can be small and performant.
|
| It takes skill, time, and work; a hard sell, these days.
|
| Nowadays, we can throw together two or three massive
| dependencies, and get a really high-tone app.
|
| That waddles like an overfed walrus.
| Karrot_Kream wrote:
| I think it's worth asking why, which I guess is less fun than
| complaining. Are the frameworks too fat? Do they encourage
| wasteful network requests? Are things not being compressed?
| Do developers not understand how to incrementally ask for
| data?
| lmm wrote:
| Everything's downstream from the incentives. What kind of
| users do you attract by making your website faster/more
| efficient? People who can't afford a new phone, and whiny
| boomer nerds. Both of those demographics are more trouble
| than they're worth.
| ChrisMarshallNY wrote:
| Speaking as a "whiny boomer nerd," I can say that another
| demographic is people that need the types of services we
| provide, and can't afford squat, because they are
| destitute, physically or mentally challenged, rebuilding
| shattered lives, or dealing with serious IRL challenges.
|
| That's the demographic that this "whiny boomer nerd"
| Serves, and they matter to me. I'm quite aware that many
| non-whiny-boomer-nerds feel as if these people should not
| exist, but they do exist, and mass murder is not an
| option, so some of us whiny boomer nerds actually care
| enough to try Serving them.
|
| Also, it's kinda fun, helping folks that can't make non-
| whiny-boomer-nerds rich, simply because it upsets non-
| whiny-boomer-nerds to see these folks experiencing better
| Quality, Security, and performance, than they do.
|
| I know that I'm kind of immature, but I've always had a
| bit of a rebellious streak.
| josephg wrote:
| Part of it is the obsession with SPAs. If your site is an
| application, it makes sense to ship a javascript blob to
| the browser and have that render everything. But 90% of
| websites aren't apps. They're news sites. They're blogs.
| They're project pages on GitHub or npm.
|
| I think the frameworks are mostly so obsessed with the
| problem of complex applications that they miss having good
| support for the simple case of server rendering with
| little-to-no javascript in the browser. If your website
| looks like a blog, it will work better if the server ships
| html to the browser. And maybe, only html. Web browsers
| handle html really well.
|
| Because you _can_ make content websites using hundreds of
| kilobytes of react, people do because that's what they
| learned at their coding bootcamp. React lets you do server
| side rendering, but it's seen as some advanced feature, not
| as the default for how we should be building the web. (In
| fairness, SSR is quite complex if you also want to re-
| hydrate in the browser).
|
| Most websites should be using tools which do server
| rendering by default.
| hutzlibu wrote:
| "Most websites should be using tools which do server
| rendering by default. "
|
| Meaning the server sends html, or the server sends an
| image?
|
| edit: html, at least with react
| ktosobcy wrote:
| I don't agree.
|
| Apart from a couple of really big websites the vast majority of
| the remaining ones could easily be a static website. course we
| ended up in dumbed down version of reality where people can't
| do without Facebook / Instagram so instead of having public
| information you have to go to a Facebook fan page or Instagram
| profile...
| tshaddox wrote:
| That's right. It's futile to fight the battle of "the web
| should never have changed after year X" where year X happens to
| be when you first got interested in the web.
| thomasfromcdnjs wrote:
| Amen.
| overgard wrote:
| I don't know, when I think about the majority of the sites I
| visit daily, it's pretty much just content. Like, let's see:
|
| - Stack Overflow
|
| - Hacker News
|
| - Reddit
|
| - Youtube
|
| - Various news blogs
|
| - Gmail
|
| - Shopping/Amazon
|
| - Maps
|
| With the exception of maps, pretty much all of that would be
| perfectly fine server side rendered (and a lot is, I think).
| Even gmail would be fine that way, tbh I find it kind of
| annoying that things like the back button work in unexpected
| ways.
|
| Things I don't do often but which would be fine server side
| even though they're SPAs:
|
| - Taxes. Turbotax is very smooth and fancy, but frankly if it
| gets my taxes done quickly I just don't care that much.
|
| Stuff that's heavy in JS, but which is pretty far weighted
| content-wise:
|
| - Twitter
|
| - Facebook
|
| - Instagram
|
| Also, a lot of the things that are essentially "web apps" I end
| up using the desktop/electron version anyway, like Slack or
| VSCode.
|
| I really think most sites would be better if JS was kept to the
| bare minimum. The things that actually act like applications
| often end up with a desktop electron version anyway.
| paxys wrote:
| None of these sites on your list would be operable without
| JavaScript, even with reduced functionality. Heck Hacker
| News, probably the gold standard for simple websites, would
| itself be unusable. You wouldn't even be able to get the
| upvote/downvote buttons to work.
| detaro wrote:
| > _Heck Hacker News, probably the gold standard for simple
| websites, would itself be unusable. You wouldn 't even be
| able to get the upvote/downvote buttons to work._
|
| Hacker News upvote/downvote buttons work without Javascript
| overgard wrote:
| That's why I said a minimum of JS, not none. You don't need
| 500KB of frameworks for an upvote button
| NoMoreNicksLeft wrote:
| I was under the impression that a few versions ago, links
| got a "ping" feature. Having an upvote icon become a link
| with a "/#" href would keep it from refreshing, and the
| ping would send data about the vote.
|
| I'm not entirely sure that sort of feature requires
| javascript at all.
| Animats wrote:
| Here's an option: have a browser set up to defer all "onload"
| Javascript until the user clicks on something. Then you see if
| you want to do anything on the page. If nothing happens until you
| let Javascript run, the page looks silly and the user goes
| elsewhere.
|
| Pages can still load CSS, so they can do formatting.
| naet wrote:
| I think this is a fine ideal for some websites but not a
| universal truth. For example I love the plaintextsports.com
| website and check it near daily on my phone, and it does a
| perfect job. And of course I agree that there is a lot of bloat
| especially around marketing / tracking snippets that slow things
| down and don't provide the end users with any upside.
|
| But there are also plenty of times when I don't want the
| minimalistic approach the author argues for. Not everything on
| the web needs to be the equivalent of a printed black and white
| pamphlet. Modern web offers so much potential for unique
| interactive experiences, storytelling, media sharing, etc that
| isn't available in print or other content mediums.
|
| Often I want to watch high res videos, or see detailed photos
| that I can zoom in on and appreciate the details. I want
| interactive JS experiences like the wonderful ciechanow.ski
| explanation tools. I want dynamic pages like a tip calculator or
| the daily wordle or a Photoshop like webapp, that I can save and
| use entirely offline. Sometimes I want a heavy gif filled homage
| to GeoCities, or a hypertext comic that blends in micro games and
| animations as part of the storytelling. I might want to check out
| a cutting edge 3d experience that only works with a special
| Chrome beta flag turned on. Sure, a subset of users on old
| hardware might not be able to enjoy it the same, but at the same
| time we have more computing power and faster connetions than
| we've ever had before, and to not use any of it would be a waste.
| The web I want is full of unique and different experiences, even
| if they're "suboptimal" in some way.
|
| There may be times when a SPA is heavy or unnecessary, but there
| are also plenty of times when it makes almost no noticeable
| difference to me if there's a couple extra megabytes on a blog
| page. If their vision or workflow is built around client-side
| heavy React rather than HTMX that's fine, that's what they were
| comfortable working with, and they were still inspired to make
| the site and share it with me often for free (and of course there
| would be tradeoffs to any other approach, like more round-trips
| to the server for minor interactions, or not being able to do fun
| page transitions, or whatever else).
| gregw134 wrote:
| Agreed. Sorry for piggybacking off your post, but I'm trying to
| build a search engine, and one thing I want to surface are
| interactive websites. Does anyone have suggestions for
| Javascript features I could extract that might indicate a site
| is doing something cool/interactive? I'm not a frontend
| developer--keywords I have now are .wasm, webhooks, WebGL,
| canvas.
| mathgladiator wrote:
| I feel the frustration, and the core of the frustration is that
| the requirements for the web were fundamentally wrong. Thus, we
| keep adding new things to the browser to enable new things.
|
| The JavaScript hate is justified for large websites where you
| download MBs of javascript. I'm discovering that a lean
| JavaScript framework and streams are a much better idiom.
|
| If I could go back in time, then I would love to long-lived
| sockets to be used rather than short-lived request-response.
| Karrot_Kream wrote:
| One of the issues with long-lived sockets is power consumption.
| Generally you need to send keep alive packets or else the
| connection is dropped and doing that forces your modem to wake
| up and send bytes.
|
| QUIC is a big step in the right direction as long as
| middleboxes don't hollow it out.
| LapsangGuzzler wrote:
| "Every great cause begins as a movement, becomes a business and
| eventually degenerates into a racket."
|
| - Eric Hoffer, The Temper of Our Time
|
| A friend gave me this quote a while back, and I find myself
| thinking about it constantly with regards to the state of tech.
| The web this author wants sounds great, but probably won't exist
| because major economic forces drive the exact pressures that
| cause these problems.
| triyambakam wrote:
| This blog post itself nearly practices what it preaches. But I
| don't see why it even needs htmx.js since it's entirely a static
| site, as far as I can tell.
| penteract wrote:
| Given the subject, it seems ironic that the page is loading
| htmx.min.js (40kB/15kB transferred). Can anyone tell if it's
| doing anything whatsoever on this page? I suspect it wasn't there
| at the time this was published but the author later added it to
| all pages on their site.
___________________________________________________________________
(page generated 2023-05-14 23:01 UTC)