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

A clean start for the web (2020)

macwright.com

Post reply on HN
Print view View original

111–120 of 200 posts

Re: A clean start for the web (2020)

#111

Post by grishka »

MrJohz wrote: post #109
gmueckl wrote: post #91

Earlier quoted context omitted.

Your rant is focused so much on the actual implementation details of Flash that it misses the point that the abstract concept of a VM based application container/sandbox could have been a great thing. In fact, it was such a great idea that browser developers were forced into a pretty tough struggle to actually kill it in order to stay relevant themselves. Adobe's poor stewardship sealed the deal, not conceptual short…

Isn't that what we have? JavaScript is a VM-based sandbox. The difference is that JavaScript has more ready access to the DOM, but Flash was also able to do that, it just used JavaScript as a bridge.

The point is that you didn't need DOM. You had a canvas to draw things on and to handle clicks in. Now you need the DOM either way and it's cumbersome. It feels like trying to build a UI in a word processor. Text nodes are such a terrible idea...

Re: A clean start for the web (2020)

#112

Post by scrollaway »

GordonS wrote: post #107
_448 wrote: post #97

Earlier quoted context omitted.

One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)

The server load from a server-side rendered page vs an API call that returns JSON is... very minimal. Unless you're building at great scale, it's such a negligible difference that it really shouldn't be part of your decision making process, IMHO.

[Edit: I don't want to get into this argument right now]

Re: A clean start for the web (2020)

#113

Post by achenet »

betwixthewires wrote: post #11

I personally would love a "document web" and an "application web." I've thought of this before independently and talked about it to some people, I think the author is right, the idea of one client application for everything internet related is a core source for the problems we face with the web. I like Gemini, a lot, and I think it could serve as a "document web" very well, except it's missing certain document featur…

you solve this by leaving an ad supported business model in favor of asking for donations.

Write a document website with a Patreon like gwern.net instead of some bloated ad-sponsored clickbait like BuzzFeed.

Re: A clean start for the web (2020)

#114

Post by bullen »

I would say .html, .css and .js and the browser are becoming over-engineered.

HTTP and SMTP are fine however.

I have stopped coding .html and only use HTTP now from a native OpenGL client written in C.

Re: A clean start for the web (2020)

#115

Post by achenet »

imiric wrote: post #67

The problems with the modern web are hardly technical. We have the technology to make it better. There is a single major problem: advertising. It is the default monetization path for most of the web, and it has become an unstoppable force of sites that are hostile to the user, siphon as much user data as possible, and use every marketing tactic available to trick the user into clicking on ads or agreeing to being tra…

ask for donations.

Make good work, people will pay to support it. Works for NPR.

Re: A clean start for the web (2020)

#116

Post by MrJohz »

locallost wrote: post #72
pronlover723 wrote: post #8

I think the web is mostly good the way it is and I don't want to see it re-invented. In fact, I hate Flutter because it's not "webby". It renderers all content and controls using Canvas which means all there is on the page is pixels which means no accessibility since there is no standard structure (the DOM) to dig through to find the content. You might say there will be solutions like ideas to augment the canvas with…

The only reason you can dig through the data now is because the browser gives you tools to do that. The primitive view source or the more advanced dev tools. A web where everything is rendered to canvas would still need to get some data and there is no reason why the browser would not give you the tools to inspect that data.

I think the point is that if the only API that's built into the browser is the canvas, then the browser itself can't know how you're actually structuring your data at all. So the most debugging you can get built in directly is telling you which lines and shapes are currently being rendered. Whereas currently, if you use the DOM, the browser can show you the full rendered tree, show you which elements have events attached, allow you to manipulate elements by putting them in specific states, or just let you delete and modify them in place. The same goes for CSS.

In practice, I suspect if this route were to become more common, then frameworks would provide these sorts of tools directly. The browser still couldn't directly see the component structure of your code, but a framework might provide a browser extension that it itself can hook into, so that you can inspect it as its running. The problem then is that each framework would have to do this separately, because there would be no single base component structure that the browser recognises.

Essentially, you'd go back to developing as it's done for desktop environments - Qt or GTK might provide their own debugging environments, but the operating system itself is generally running at a much lower level, and so can't help you much if you want to know why "foo" is being rendered instead of "bar".

Re: A clean start for the web (2020)

#117

Post by chrischen »

iamcurious wrote: post #46
grishka wrote: post #35

Earlier quoted context omitted.

> What if I want documents with a slight bit of inactivity? Then you use Adobe Flash. See, we used to have a decent technology for when you want "a document with a slight bit of interactivity". It worked very well for this exact purpose. More than 10 years later, browsers' native capabilities, that are supposed to be a replacement for what Flash offered, have still not quite caught up. Moreover, Flash defined a clear…

Cool, since you are here , is there any flash editor clone? That was the stuff, animations, games, apps, all so intuitive.

Try https://tumult.com/hype/

Re: A clean start for the web (2020)

#118

Post by recursivedoubts »

dgb23 wrote: post #100
recursivedoubts wrote: post #30

What we need is for HTML to get going as a hypermedia again, to make the hypermedia architecture viable for a larger set of web applications. It's been stalled at anchors and forms (with only GET and POST!) for decades now. It's astounding how much we got built with just that. I'm trying to show where it could go with htmx: https://htmx.org Hypermedia (in particular the uniform interface) is what made the web special…

Htmx is very well designed library and I‘ve been using it more and more. It’s great to have it in my toolbox. The reason it, and the many other cool libraries can exist is borne out of the strength of the web, namely a solid, accessible foundation of protocols and formats with extensibility via JavaScript. This last part is incredibly important, because it gives us enough power to create and explore new things, while…

agreed, fielding specifically mentions scripting as an optional constraint in section 5.1.5 of his dissertation, "Code on Demand":

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

and it has proven to be an incredibly flexible aspect of the web

however, I would note, currently that scripting ability is being used mainly to replace the original hypermedia model of the web (with RPC-style JSON-based applications) rather than enhance it as a hypermedia

we'll see if we can change that

Re: A clean start for the web (2020)

#119

Post by recursivedoubts »

scrollaway wrote: post #112
GordonS wrote: post #107

Earlier quoted context omitted.

The server load from a server-side rendered page vs an API call that returns JSON is... very minimal. Unless you're building at great scale, it's such a negligible difference that it really shouldn't be part of your decision making process, IMHO.

[Edit: I don't want to get into this argument right now]

the original web architecture has sophisticated client-side caching built into it, all modern browsers support it:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

the difference between constructing a string of JSON and a string of HTML is a round off error when compared with network connection costs and data store accesses, etc.

Re: A clean start for the web (2020)

#120

Post by recursivedoubts »

egeozcan wrote: post #104
thestepafter wrote: post #99

Earlier quoted context omitted.

I have been reading a lot about HTMX and planning to develop an app in it on top of a JSON API. With that being said do you know if any open source apps that do authentication on top of a JSON API using HTMX? I’m having trouble conceptualizing the structure and flow of data from just reading the docs. Primarily around maintaining state between pages. (Looking to use JWT for authentication.)

htmx is designed to work with a HTML API. Everyone here seems to love it, I found it forces terribly complicated routing and templating and IMHO projects grow towards unmaintainable very quickly. I'm saying this as a person who really tried hard to like it. You can perhaps use Alpine.js plus sprinkle htmx here and there, to have the best of both worlds, at least on paper. Didn't try this myself.

i'm old enough to remember when everyone here hated it ;)
Post reply on HN