30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
Good response, opinions are always worth having, as long as you are prepared to discuss/defend/change them! I had a few thoughts on this topic last year in response to your good self and web components that I think is worth referring back to: dev.to/phlash909/comment/cghl
In essence, the DOM and page model of HTML is a constraint around the outside of applications that might be better inverted: I'd like to see browsers that support HTML/DOM content if required, but do not constrain devs to always go though it. Let's stop thinking of them as HTML rendering engines, and start thinking of pre-installed runtimes with excellent web-based application management!
We'll want to retain the benefits of dynamic software running on the client (native UX, easy architecture changes, no user-install step, etc.), while leveraging the effort that goes into making that a portable & safe thing to do (common APIs, sandboxes, browsers as the standard runtime for client-side applications). We are nearly there with PWAs perhaps? WASM then expands the available languages for the runtime, allowing common client/server languages and development processes to ease developer adoption. As/when a document needs rendering, then HTML/DOM/CSS is there to perform it's proper function, however many apps many be better off with a UX library (eg: SDL) or widget set (eg: wxWidgets) atop the runtime bindings.
I believe at the point you fundamentally push to render things other than markup, you start making a different application. And that is perfectly reasonable. I’m frankly surprised how well HTTP has held up to so many use cases. I long ago expected to see far more protocols for more kinds of apps, but HTTP seems to have solved so many problems well enough that it now hosts other protocols.
There are probably more protocols that could be written and hosted on other ports. Those would likely address many of these issues in a far better way. I just wonder when the industry will pivot back to building protocols and leave HTTP well enough alone.
I think we're past that as most recent innovations in the web space are either formats or evolutions of HTTP. Why reinvent the wheel if the wheel works well? What do you think?
HTTP/3 with QUIC seems like a great improvement, but it is changing HTTP. I don’t see why HTTP needs changing for most things. Why not update SMTP or FTP, as well? QUIC solves specific problems, and it might be better for those who need QUIC for it to have features better suited to their needs.
In some ways, this also feels like the mash of several formats into HTML5 to avoid name spacing. While we focus on and champion components within our own apps, we continue to avoid and break components in the infrastructure.
Therefore, I think we may see new protocols emerge as the weight of these complexities begin to cause problems. That could still be some way off.
I'm not sure it is changing HTTP, it's HTTP over UDP. The protocol is basically the same as HTTP/1 and HTTP/2.
QUIC solves specific problems, and it might be better for those who need QUIC for it to have features better suited to their needs.
QUIC solves a specific problem HTTP has because it sits on top of TCP though, basically pipelining
In some ways, this also feels like the mash of several formats into HTML5 to avoid name spacing. While we focus on and champion components within our own apps, we continue to avoid and break components in the infrastructure.
I'm not sure I follow the analogy with HTML5, sorry :( IIRC HTML5 was created to stop having to revise HTML as a a single unit and let things evolve at their own pace. Same with CSS 3 I guess. I don't think it's the same thing here: HTTP/3 is the result of the entire world using HTTP and needing to improve performance.
Could they have created a new protocol? Sure, but why break compatibility with millions of browsers, proxies, machines, software application and so on that understand and function through HTTP? I think the decision to rewrite the transport layer to be a smart one.
This doesn't mean that other protocols can't emerge, but it's okay not to throw away those that work already
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
Good response, opinions are always worth having, as long as you are prepared to discuss/defend/change them! I had a few thoughts on this topic last year in response to your good self and web components that I think is worth referring back to: dev.to/phlash909/comment/cghl
In essence, the DOM and page model of HTML is a constraint around the outside of applications that might be better inverted: I'd like to see browsers that support HTML/DOM content if required, but do not constrain devs to always go though it. Let's stop thinking of them as HTML rendering engines, and start thinking of pre-installed runtimes with excellent web-based application management!
We'll want to retain the benefits of dynamic software running on the client (native UX, easy architecture changes, no user-install step, etc.), while leveraging the effort that goes into making that a portable & safe thing to do (common APIs, sandboxes, browsers as the standard runtime for client-side applications). We are nearly there with PWAs perhaps? WASM then expands the available languages for the runtime, allowing common client/server languages and development processes to ease developer adoption. As/when a document needs rendering, then HTML/DOM/CSS is there to perform it's proper function, however many apps many be better off with a UX library (eg: SDL) or widget set (eg: wxWidgets) atop the runtime bindings.
I believe at the point you fundamentally push to render things other than markup, you start making a different application. And that is perfectly reasonable. I’m frankly surprised how well HTTP has held up to so many use cases. I long ago expected to see far more protocols for more kinds of apps, but HTTP seems to have solved so many problems well enough that it now hosts other protocols.
There are probably more protocols that could be written and hosted on other ports. Those would likely address many of these issues in a far better way. I just wonder when the industry will pivot back to building protocols and leave HTTP well enough alone.
I think we're past that as most recent innovations in the web space are either formats or evolutions of HTTP. Why reinvent the wheel if the wheel works well? What do you think?
HTTP/3 with QUIC seems like a great improvement, but it is changing HTTP. I don’t see why HTTP needs changing for most things. Why not update SMTP or FTP, as well? QUIC solves specific problems, and it might be better for those who need QUIC for it to have features better suited to their needs.
In some ways, this also feels like the mash of several formats into HTML5 to avoid name spacing. While we focus on and champion components within our own apps, we continue to avoid and break components in the infrastructure.
Therefore, I think we may see new protocols emerge as the weight of these complexities begin to cause problems. That could still be some way off.
I'm not sure it is changing HTTP, it's HTTP over UDP. The protocol is basically the same as HTTP/1 and HTTP/2.
QUIC solves a specific problem HTTP has because it sits on top of TCP though, basically pipelining
I'm not sure I follow the analogy with HTML5, sorry :( IIRC HTML5 was created to stop having to revise HTML as a a single unit and let things evolve at their own pace. Same with CSS 3 I guess. I don't think it's the same thing here: HTTP/3 is the result of the entire world using HTTP and needing to improve performance.
Could they have created a new protocol? Sure, but why break compatibility with millions of browsers, proxies, machines, software application and so on that understand and function through HTTP? I think the decision to rewrite the transport layer to be a smart one.
This doesn't mean that other protocols can't emerge, but it's okay not to throw away those that work already
If you were to remove the "web-based" part, it'd almost describe the beginning of OSes back in the day.
Which is perhaps what they are: The UI part of a vast "operating system" by which we access the "applications" of the internet.