5 ms·

I'd go further than this and suggest that web applications, sites that don't display anything without executing code, are not web at all. They just use web prot

I'd go further than this and suggest that web applications, sites that don't display anything without executing code, are not web at all. They just use web protocol to transfer the executable. And pretty soon most web applications will switch to using HTTP/3 implemented on QUIC so they won't even be using HTTP.

notyourwork 4y ago
Ding, ding, ding! We started diverging from the "web" long ago with the introduction of SPA.
- lolive 4y ago
  Funnily, the fact that Google can only index resources/documents associated to a URL has saved the whole concept of the web (for now). Note: and the fact that there is no search engine inside companies has led them to disregard the concept of permalinks. All SPAs there simply never change the URL in the address bar. Which is an HORRIBLE experience as a user!
  - foobarian 4y ago
    > Funnily, the fact that Google can only index resources/documents associated to a URL has saved the whole concept of the web (for now). That's a great point. You wouldn't believe the hemming and hawing that ensues at work when teams encounter SEO-driven constraints.
  - nr2x 4y ago
    Wow, good point.
samwillis 4y ago
The web platform, HTML/js/css in a browser, is one of the greatest inventions of all time. Its versatility is immeasurable. The fact we have one toolkit that scales from a simple text based publishing platform to full application development environment, is insane. It covers all paradigms of computing, from thin client to full offline enabled local computing. It is incredible that the community have built this general purpose platform, and that it's not only versatile but also incredibly performant. Modern JS engines are only 50% the speed of native C, no compiler or toolkit needed. How insane is that! CSS/HTML is growing from strength to strength, it's a gui toolkit with so much power universally supported on all computing platforms, from phones to desktops. It has so many features, and is so extendable, but anyone can use it anywhere. There's no limit to its capability, or who can use it to build their inventions. The same toolkit can be used by small children to explore the ideas around "programming" all the way up to the best developers in the world. Honestly the argument that we have somehow gone wrong with html/css/js is absurd. What this platform has contributed to humanity is immeasurable. The "original vision" of the web as a publishing platform for text may be dead. But it lives on as a publishing platform for human invention, ingenuity and creativity.
- beebmam 4y ago
  This is beautifully said and absolutely true. The HTML/js/css platform is truly incredible. Looking forward to seeing how people can use WASM in incredible ways!
  - samwillis 4y ago
    Absolutely, and like all new things some of the original uses will not work out but what it brings to the table is awesome. (I'm unconvinced by trying to "speed up" normal web apps with it) The two places I'm most excited about it is using it in combination with WebGPU for games/engineering/ai/science, and with the "origin privet file system" enabling client side databases such as SQLite and DuckDB. I think it's the final peace of the jigsaw to make PWAs take off like a rocket. Honestly, PWAs are the true future of the web, the perfect extension of its vision.
  - tracker1 4y ago
    I have somewhat mixed feelings on WASM... you can't "peak" into it nearly as much as JS... but even JS has gone past the point of being really decipherable by humans in production sites for a while. I know there's some boundary issues with performance and hope that it can be worked out in a meaningful/reasonable way. I think WASM gets much more interesting in server hosted platform environments. You get largely portable code that can run wherever (x86, arm, risc-v, etc) and is in a secure environment, read-only into itself.
    - qu4z-2 4y ago
      JavaScript has, for better or worse, become Flash.
      - tracker1 4y ago
        The exception being that JS's sandbox isn't the sieve that Flash was.
- kaba0 4y ago
  While I absolutely agree regarding the immeasurable contribution to humanity part, I feel it happened despite HTML/CSS, not because of it. I still think that it is a very inefficient and bad abstraction for general purpose layouts and only recently with flexbox/grid did it basically got feature-parity with things like.. WinForms. Js used to be pretty bad as well, but hats down, they did alleviate many of the shortcomings and made it into a decent language (though I do get grumpy when it is overused at places where it has no reason to be)
cmckn 4y ago
> soon most web applications will switch to using HTTP/3 implemented on QUIC so they won't even be using HTTP. HTTP/3 is definitely still HTTP. QUIC is replacing TCP.
- superkuh 4y ago
  HTTP/3 is HTTP because Google and Microsoft said so and had the people in place to push it through the IETF. It's not really HTTP like HTTP/1.1 was and is; designed for human people to interact with for web sites made out of pages. It's a protocol designed for web applications. This is so deep in it's core it won't even allow you to connect to another IP unless you get continuing approval from an incorporated entity running a CA to lease a TLS cert.
  - Seirdy 4y ago
    QUIC does not require a CA. Self-signed or DANE-backed TLS certificates work fine. Try using cURL built with HTTP/3 support to see for yourself. Requiring CAs and not implementing support for other anchors of trust is an implementation decision, and is not mandated by the spec. The spec mandates TLS 1.3, not "the version of TLS 1.3 used by these three web browsers". QUIC was designed with non-browser use in mind too; it's for any situation where you want to maintain connection integrity in an unreliable network.
    - superkuh 4y ago
      True in theory, not true in practice. It might work if all the random people on the internet used cURL to visit my websites but they tend to use browsers that are Chrome based. And Chrome's QUIC (or the underlying quiche library) differs how Chrome's H1 and H2 implement TLS. It will not accept a self-signed cert during a HTTP3 QUIC connection. Even going localhost (defeats the point, but to check) and trying --disable_certificate_verification --allow-insecure-localhost will not work. Like I said, the megacorps that designed QUIC designed it for their use cases and that does not include allowing human people to host websites by themselves. Not if it potentially impacts e-commerce security. Their implementations reflect this.
stepanhruda 4y ago
It’s only HTTP if it comes from the 1.1 region of France, otherwise it’s sparkling bytes?

notyourwork 4y ago

Ding, ding, ding! We started diverging from the "web" long ago with the introduction of SPA.

lolive 4y ago
Funnily, the fact that Google can only index resources/documents associated to a URL has saved the whole concept of the web (for now). Note: and the fact that there is no search engine inside companies has led them to disregard the concept of permalinks. All SPAs there simply never change the URL in the address bar. Which is an HORRIBLE experience as a user!
- foobarian 4y ago
  > Funnily, the fact that Google can only index resources/documents associated to a URL has saved the whole concept of the web (for now). That's a great point. You wouldn't believe the hemming and hawing that ensues at work when teams encounter SEO-driven constraints.
- nr2x 4y ago
  Wow, good point.

samwillis 4y ago

The web platform, HTML/js/css in a browser, is one of the greatest inventions of all time. Its versatility is immeasurable. The fact we have one toolkit that scales from a simple text based publishing platform to full application development environment, is insane. It covers all paradigms of computing, from thin client to full offline enabled local computing. It is incredible that the community have built this general purpose platform, and that it's not only versatile but also incredibly performant. Modern JS engines are only 50% the speed of native C, no compiler or toolkit needed. How insane is that! CSS/HTML is growing from strength to strength, it's a gui toolkit with so much power universally supported on all computing platforms, from phones to desktops. It has so many features, and is so extendable, but anyone can use it anywhere. There's no limit to its capability, or who can use it to build their inventions. The same toolkit can be used by small children to explore the ideas around "programming" all the way up to the best developers in the world. Honestly the argument that we have somehow gone wrong with html/css/js is absurd. What this platform has contributed to humanity is immeasurable. The "original vision" of the web as a publishing platform for text may be dead. But it lives on as a publishing platform for human invention, ingenuity and creativity.

beebmam 4y ago
This is beautifully said and absolutely true. The HTML/js/css platform is truly incredible. Looking forward to seeing how people can use WASM in incredible ways!
- samwillis 4y ago
  Absolutely, and like all new things some of the original uses will not work out but what it brings to the table is awesome. (I'm unconvinced by trying to "speed up" normal web apps with it) The two places I'm most excited about it is using it in combination with WebGPU for games/engineering/ai/science, and with the "origin privet file system" enabling client side databases such as SQLite and DuckDB. I think it's the final peace of the jigsaw to make PWAs take off like a rocket. Honestly, PWAs are the true future of the web, the perfect extension of its vision.
- tracker1 4y ago
  I have somewhat mixed feelings on WASM... you can't "peak" into it nearly as much as JS... but even JS has gone past the point of being really decipherable by humans in production sites for a while. I know there's some boundary issues with performance and hope that it can be worked out in a meaningful/reasonable way. I think WASM gets much more interesting in server hosted platform environments. You get largely portable code that can run wherever (x86, arm, risc-v, etc) and is in a secure environment, read-only into itself.
  - qu4z-2 4y ago
    JavaScript has, for better or worse, become Flash.
    - tracker1 4y ago
      The exception being that JS's sandbox isn't the sieve that Flash was.
kaba0 4y ago
While I absolutely agree regarding the immeasurable contribution to humanity part, I feel it happened despite HTML/CSS, not because of it. I still think that it is a very inefficient and bad abstraction for general purpose layouts and only recently with flexbox/grid did it basically got feature-parity with things like.. WinForms. Js used to be pretty bad as well, but hats down, they did alleviate many of the shortcomings and made it into a decent language (though I do get grumpy when it is overused at places where it has no reason to be)

cmckn 4y ago

> soon most web applications will switch to using HTTP/3 implemented on QUIC so they won't even be using HTTP. HTTP/3 is definitely still HTTP. QUIC is replacing TCP.

superkuh 4y ago
HTTP/3 is HTTP because Google and Microsoft said so and had the people in place to push it through the IETF. It's not really HTTP like HTTP/1.1 was and is; designed for human people to interact with for web sites made out of pages. It's a protocol designed for web applications. This is so deep in it's core it won't even allow you to connect to another IP unless you get continuing approval from an incorporated entity running a CA to lease a TLS cert.
- Seirdy 4y ago
  QUIC does not require a CA. Self-signed or DANE-backed TLS certificates work fine. Try using cURL built with HTTP/3 support to see for yourself. Requiring CAs and not implementing support for other anchors of trust is an implementation decision, and is not mandated by the spec. The spec mandates TLS 1.3, not "the version of TLS 1.3 used by these three web browsers". QUIC was designed with non-browser use in mind too; it's for any situation where you want to maintain connection integrity in an unreliable network.
  - superkuh 4y ago
    True in theory, not true in practice. It might work if all the random people on the internet used cURL to visit my websites but they tend to use browsers that are Chrome based. And Chrome's QUIC (or the underlying quiche library) differs how Chrome's H1 and H2 implement TLS. It will not accept a self-signed cert during a HTTP3 QUIC connection. Even going localhost (defeats the point, but to check) and trying --disable_certificate_verification --allow-insecure-localhost will not work. Like I said, the megacorps that designed QUIC designed it for their use cases and that does not include allowing human people to host websites by themselves. Not if it potentially impacts e-commerce security. Their implementations reflect this.

stepanhruda 4y ago

It’s only HTTP if it comes from the 1.1 region of France, otherwise it’s sparkling bytes?