Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Web I Want (2018)

quii.dev

Post reply on HN
Print view View original

51–60 of 70 posts

Re: The Web I Want (2018)

#51

Post by NoMoreNicksLeft »

paxys wrote: post #47
overgard wrote: post #46

Earlier quoted context omitted.

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 t…

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.

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.

Re: The Web I Want (2018)

#52

Post by lmm »

Karrot_Kream wrote: post #31
ChrisMarshallNY wrote: post #27

Earlier quoted context omitted.

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.

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?

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.

Re: The Web I Want (2018)

#53

Post by ChrisMarshallNY »

lmm wrote: post #52
Karrot_Kream wrote: post #31

Earlier quoted context omitted.

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?

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.

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 helping 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 “not worth the trouble” folks experiencing better Quality, Security, and performance, than the non-whiny-boomer-nerds do.

I know that it’s kind of immature, but I've always had a bit of a rebellious streak, and I’m easily amused.

Re: The Web I Want (2018)

#54

Post by Conscat »

TacticalCoder wrote: post #30

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 win…

That's an interesting idea I might have to try out!

Re: The Web I Want (2018)

#55

Post by rektide »

There's a lot of good heart here & I dig it.

But the web isn't just for documents & exploring content. Or the content is complex & interesting & rightfully semi dynamic.

I really worry & grow concerned when people impose their quasi-religious beliefs about what the web is for. There's absolutely real harm & bad, and much of it comes from the crazy institutional/industrial nature of software development and many of our current tools have degraded the humanness of the web. The harms are real.

But so many people for so many widely different/opposing reasons want us to abandon HTML, and it's so hard for me to imagine what open society is left with if we move all app development back to native stacks. The Towards A Modern Web Stack view is that app makers can just target the web as a dumb delivery target, with WebGPU & webusb HID instead of html & the html events. They are horseshoe views, that almost meet in agreeing that html shouldn't be for X or shouldn't be for Y.

Identifying problems & desire ables are great. But we seem to have a small but very vocal group that decides & loudly advocates for what we can't use the web for. So so many of these concerns seem implementation & company specific. And these ills- so many of them would best be remedied by getting better at html webdev, by finding different paths to app building, ideally that are more We Component based, that make the page more honest & truthful & manipulable & up front. If we just categorically try to make the web unable to have these problems, humanity will be even less well equipped, have less agency to fight the hydra of capitalist dominion where it arises elsewhere.

Re: The Web I Want (2018)

#56

Post by andrewfong »

josephg wrote: post #43
andrewfong wrote: post #37

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…

> 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?

By virtual DOM, what I mean is telling the browser I would like to replace the innerHTML of an element with another bit of HTML, and the browser should figure out an efficient way to "diff" the update rather than replace all the children wholesale.

It would not be as efficient as Svelte and Solid since those can use the compiler to further optimize code, but having the framework-less version of JS be "as good as" a framework like Vue or React would be a big plus for moving away from frameworks generally.

Apart from that, the general problem of reactivity boils down to "map this DOM element to this variable, and if the variable changes, update the DOM element". You could imagine an API sort of like this:

  
    Default Value
Where `bind-var` specifies a variable that, if updated, signals that the span should be replaced with the return value of the function specified by `bind-gen`

Re: The Web I Want (2018)

#57

Post by josephg »

hutzlibu wrote: post #44
josephg wrote: post #42

Earlier quoted context omitted.

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…

"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

Yes, HTML.

HTML is faster to load on all devices, usually smaller over the wire, trivially cacheable at every level. Its easier to debug, easier to archive or backup, and it plays nicely with screen readers, search engines and reader mode. The back button always works and does what the user expects. And it looks web-native everywhere.

I wrote a 9000 word blog post a couple years ago covered in diagrams. The page renders near-instantly on all browsers I've tried, and scrolling is buttery smooth. How did I do that? Its simple. When users open the webpage, I send them an HTML file.

Re: The Web I Want (2018)

#58

Post by [deleted] »

bbbbzzz1 wrote: post #4

> 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.

[deleted]

Re: The Web I Want (2018)

#59

Post by josephg »

andrewfong wrote: post #56
josephg wrote: post #43

Earlier quoted context omitted.

> 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?

By virtual DOM, what I mean is telling the browser I would like to replace the innerHTML of an element with another bit of HTML, and the browser should figure out an efficient way to "diff" the update rather than replace all the children wholesale. It would not be as efficient as Svelte and Solid since those can use the compiler to further optimize code, but having the framework-less version of JS be "as good as" a f…

> By virtual DOM, what I mean is telling the browser I would like to replace the innerHTML of an element with another bit of HTML, and the browser should figure out an efficient way to "diff" the update rather than replace all the children wholesale.

Yeah, I know what you mean. And I agree that something like that could be faster than react if it were written in C++. But if we're going to bake something into the browser, I'd like it to be something good. The "Regenerate big chunks of HTML then do expensive tree-diffing operations" approach is, as you say, always going to be less efficient than how Svelte or Solid render. I'd much rather skip DOM diffing entirely and go straight to that.

> Where `bind-var` specifies a variable that, if updated, signals that the span should be replaced with the return value of the function specified by `bind-gen`

Nice - thanks for the example. I suppose the trick is implementing this in such a way that it doesn't depend on "watching" a variable in javascript. (Well, or we'd need to also add that as a feature to javascript - which would be a bit wild.)

Re: The Web I Want (2018)

#60

Post by paulryanrogers »

andrewfong wrote: post #37

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…

> There's the obvious stuff, like simply blocking third party tracking JS.

Doubtful this will ever be a mainstream default. If by some miracle it did then I imagine CNAME cloaking or proxying via first party would immediately take hold. Not necessarily bad but certainly very disruptive to the status quo.

It's also not clear how browsers could do it. Do you prevent all network calls from scripts loaded from a 3P host? Do you similarly lock 1P scripts to only making network calls to 1P hosts?

Post reply on HN