7 ms·

This may sound sort of “old man waves at cloud” of me but one thing I’ve found sad is the gross over-complication of later versions of standards such that the s

by samtho 3y ago

This may sound sort of “old man waves at cloud” of me but one thing I’ve found sad is the gross over-complication of later versions of standards such that the sort of project linked here may not be as practical for something like HTTP/3 for example. Similarly, the large, muddled tool chain that is “required” to make modern JavaScript applications makes it hard for newer learners to really understand what is going on because the minimal code version still needs its own transpiler, build system, linter, process managers, etc. Maybe we need all this complexity, but I suspect that some of the overzealous, solve-everything systems design we have come accustomed to is mainly serving to create a larger problem set instead of creating elegant abstractions that are agreed upon.

skaushik92 3y ago
I see what you’re saying and agree that HTTP3 is complicated but I would that since it’s a backwards compatible standard, the added complexities are completely optional. For most use cases the basic protocol is perfectly suitable and only as the scale evolves does it require the additional complexity.
- samtho 3y ago
  I understand what you’re saying, but if someone decides to post a link to their project that is an HTTP/3 server in under X lines of code but only implements HTTP/2 features, is it really an HTTP/3 web server?
  - fsckboy 3y ago
    the HTTP/3 standard for servers is not backward compatible with HTTP/2 servers, it is backward compatible with HTTP/2 clients. And vice versa And therefore, an HTTP/2 server calling itself compatible with HTTP/3 clients is OK
    - samtho 3y ago
      It might be OK on a technical level, but my concern is where someone is showing off a project they used to supposedly learn how to implement HTTP/3 but only goes far enough to use an HTTP/2 implementation because fully implementing 3 is too complex or not worth it.
  - skaushik92 3y ago
    Where does it say it is an HTTP/3 server? Looking at the tests it seems that it’s just a HTTP/1 server I think.
GuB-42 3y ago
The big thing that makes HTTP/2, HTTP/3 and even Gemini hard to implement is TLS. I theory, HTTP/2 don't require it, but in practice, it does. You need to implement a variety of ciphers, manage certificates with expiration dates, etc... And if you wanted to implement all that yourself, people will yell at you for doing your own crypto. So yeah, you need a library. But not just that. You need a way to update your certificates, so you can't have a package (or even a single executable) that you can just run and have a server that serves static pages. You could make a self-signed certificate that lasts a thousand years, but good luck getting it accepted.
- wahern 3y ago
  Generally speaking, you also need some sort of an operating system to make use of HTTP, and yet that doesn't figure into the complexity of HTTP. In classic HTTP TLS was layered beneath it, providing important degrees of freedom, including the freedom to not use TLS, which can be especially important for experimentation and development. Prediction: If HTTP/3 manages to substantially replace classic HTTP+TLS, QUIC is destined to become a kernel-provided service like TCP, shunting all that complexity behind an OS abstraction and freeing user space. The fact QUIC uses UDP is an important aspect here because a performant userspace QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes; abstractions which make it viable (i.e. cheap) to have a rich, diverse ecosystem of languages and execution environments in userspace. More importantly, HTTP will have come full circle.
  - bongobingo1 3y ago
    > QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes; abstractions which make it viable (i.e. cheap) to have a rich, diverse ecosystem of languages and execution environments in userspace Do you mind expanding on that with a sentence or two?
    - friendzis 3y ago
      UDP is streams in the very classical definition: stream objects (bytes, probably, though a more faithful implementation would contain chunks/arrays) go out without predefined start/end. In other words, imagine that a single `read()` (or whatever) call returns random chunk from HTML source and it is your job to make sense of where in the space of whole page that chunk comes from. There is even no guarantee that consecutive read will return data "in order". "File" abstraction layer has predefined start, end, length, order, and so on. You need some buffering magic layer on top of UDP that provides facilities mandated by file abstraction layer.
sharikone 3y ago
Some elegant abstractions are created too. JS modules, for example. Or, in another field, the Language Server Protocol. But yes, humans are humans and everything that is "simple" will get built upon and then become the backbone of something complex that will engulf and smother it as it evolves.
deleted 3y ago
[deleted]
kragen 3y ago
i'm concerned about this too google isn't really concerned about creating elegant abstractions so much as they are about improving the performance of their browser talking to their server, though sometimes these do coincide
paulddraper 3y ago
It can be simple, or it can be fast. Or it can be neither. But it can't be both. If you want fast web at all cost (and you need encryption), you get HTTP3/QUIC.
- samtho 3y ago
  At the end of the day, the question is never one debating simplicity. If you consider the amount of complexity implemented just to even boot into an operating system to run these systems, the lack of simplicity is already a forgone conclusion. The crux of issue is going back to abstractions and my worry is specific to how our abstractions are getting larger and larger and doing more work at even level with very tight coupling rather than creating systems that use more levels as needed.
  - paulddraper 3y ago
    And that's a question that goes back to the very first network discussions. The IP model won over the OSI model due to lower number of larger layers. I think it's a very reasonable question, but also the HTTP3/QUIC advantages do seem to offer advantages.
jacquesm 3y ago
> Similarly, the large, muddled tool chain that is “required” to make modern JavaScript applications makes it hard for newer learners to really understand what is going on because the minimal code version still needs its own transpiler, build system, linter, process managers, etc. We built pianojacq.com without all that, just plain vanilla JS and a minimum of dependencies, see: https://gitlab.com/jmattheij/pianojacq https://gitlab.com/jmattheij/pianojacq
- cpach 3y ago
  Hey, I really like the choice of default song you chose :)
  - jacquesm 3y ago
    Bach WTK prelude 1? It was the first real piece I ever learned so that's why it's there :)
    - cpach 3y ago
      I was thinking about Frère Jacques :)
      - jacquesm 3y ago
        Haha, ah, that one :) Yes, but that was just to have something (anything) really on the display after you load the program, pure coincidence ;)
treve 3y ago
I relate to the general concern about complexity creep a lot, but in the HTTP/1/2/3 case I'm just not terribly worried. So much effort has been put into backwards compatibility. The only potential true new concept that comes to mind is PUSH, which clients can ignore and mostly failed. HTTP/2 has been around for almost 10 years and I haven't seen a single implementation require it.
ttymck 3y ago
This is a result of trying to make HTTP "do everything well", right? Instead of leaving it to each application to select a layering of successive protocols tailored to it's needs, everything has been jammed into the HTTP spec, which has the nice property of giving you all its features in web browser clients (which is the delivery mechanism for this wide array of apps). Certainly some applications need not have access to the entire HTTP suite. If the goal is not to offer a "full-featured" client then an HTTP client may not be terribly difficult, it can just fail gracefully if the other party tries to do something it doesn't support?
raxxorraxor 3y ago
I will yell at the cloud too. I get why TypeScript exists. For large projects it really helps. But loosing one of the main benefits of scripting languages for some convenience? You could argue that you use webpack anyway. Same question applies here... If you have to use JS anyway, be glad that you can have an extremely shallow toolchain for deployment for smaller projects. I am not a JS dev, I just use it for stabbing at bits occasionally.

by samtho 3y ago

skaushik92 3y ago

I see what you’re saying and agree that HTTP3 is complicated but I would that since it’s a backwards compatible standard, the added complexities are completely optional. For most use cases the basic protocol is perfectly suitable and only as the scale evolves does it require the additional complexity.

samtho 3y ago
I understand what you’re saying, but if someone decides to post a link to their project that is an HTTP/3 server in under X lines of code but only implements HTTP/2 features, is it really an HTTP/3 web server?
- fsckboy 3y ago
  the HTTP/3 standard for servers is not backward compatible with HTTP/2 servers, it is backward compatible with HTTP/2 clients. And vice versa And therefore, an HTTP/2 server calling itself compatible with HTTP/3 clients is OK
  - samtho 3y ago
    It might be OK on a technical level, but my concern is where someone is showing off a project they used to supposedly learn how to implement HTTP/3 but only goes far enough to use an HTTP/2 implementation because fully implementing 3 is too complex or not worth it.
- skaushik92 3y ago
  Where does it say it is an HTTP/3 server? Looking at the tests it seems that it’s just a HTTP/1 server I think.

GuB-42 3y ago

The big thing that makes HTTP/2, HTTP/3 and even Gemini hard to implement is TLS. I theory, HTTP/2 don't require it, but in practice, it does. You need to implement a variety of ciphers, manage certificates with expiration dates, etc... And if you wanted to implement all that yourself, people will yell at you for doing your own crypto. So yeah, you need a library. But not just that. You need a way to update your certificates, so you can't have a package (or even a single executable) that you can just run and have a server that serves static pages. You could make a self-signed certificate that lasts a thousand years, but good luck getting it accepted.

wahern 3y ago
Generally speaking, you also need some sort of an operating system to make use of HTTP, and yet that doesn't figure into the complexity of HTTP. In classic HTTP TLS was layered beneath it, providing important degrees of freedom, including the freedom to not use TLS, which can be especially important for experimentation and development. Prediction: If HTTP/3 manages to substantially replace classic HTTP+TLS, QUIC is destined to become a kernel-provided service like TCP, shunting all that complexity behind an OS abstraction and freeing user space. The fact QUIC uses UDP is an important aspect here because a performant userspace QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes; abstractions which make it viable (i.e. cheap) to have a rich, diverse ecosystem of languages and execution environments in userspace. More importantly, HTTP will have come full circle.
- bongobingo1 3y ago
  > QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes; abstractions which make it viable (i.e. cheap) to have a rich, diverse ecosystem of languages and execution environments in userspace Do you mind expanding on that with a sentence or two?
  - friendzis 3y ago
    UDP is streams in the very classical definition: stream objects (bytes, probably, though a more faithful implementation would contain chunks/arrays) go out without predefined start/end. In other words, imagine that a single `read()` (or whatever) call returns random chunk from HTML source and it is your job to make sense of where in the space of whole page that chunk comes from. There is even no guarantee that consecutive read will return data "in order". "File" abstraction layer has predefined start, end, length, order, and so on. You need some buffering magic layer on top of UDP that provides facilities mandated by file abstraction layer.

sharikone 3y ago

Some elegant abstractions are created too. JS modules, for example. Or, in another field, the Language Server Protocol. But yes, humans are humans and everything that is "simple" will get built upon and then become the backbone of something complex that will engulf and smother it as it evolves.

deleted 3y ago

[deleted]

kragen 3y ago

i'm concerned about this too google isn't really concerned about creating elegant abstractions so much as they are about improving the performance of their browser talking to their server, though sometimes these do coincide

paulddraper 3y ago

It can be simple, or it can be fast. Or it can be neither. But it can't be both. If you want fast web at all cost (and you need encryption), you get HTTP3/QUIC.

samtho 3y ago
At the end of the day, the question is never one debating simplicity. If you consider the amount of complexity implemented just to even boot into an operating system to run these systems, the lack of simplicity is already a forgone conclusion. The crux of issue is going back to abstractions and my worry is specific to how our abstractions are getting larger and larger and doing more work at even level with very tight coupling rather than creating systems that use more levels as needed.
- paulddraper 3y ago
  And that's a question that goes back to the very first network discussions. The IP model won over the OSI model due to lower number of larger layers. I think it's a very reasonable question, but also the HTTP3/QUIC advantages do seem to offer advantages.

jacquesm 3y ago

> Similarly, the large, muddled tool chain that is “required” to make modern JavaScript applications makes it hard for newer learners to really understand what is going on because the minimal code version still needs its own transpiler, build system, linter, process managers, etc. We built pianojacq.com without all that, just plain vanilla JS and a minimum of dependencies, see: https://gitlab.com/jmattheij/pianojacq https://gitlab.com/jmattheij/pianojacq

cpach 3y ago
Hey, I really like the choice of default song you chose :)
- jacquesm 3y ago
  Bach WTK prelude 1? It was the first real piece I ever learned so that's why it's there :)
  - cpach 3y ago
    I was thinking about Frère Jacques :)
    - jacquesm 3y ago
      Haha, ah, that one :) Yes, but that was just to have something (anything) really on the display after you load the program, pure coincidence ;)

treve 3y ago

I relate to the general concern about complexity creep a lot, but in the HTTP/1/2/3 case I'm just not terribly worried. So much effort has been put into backwards compatibility. The only potential true new concept that comes to mind is PUSH, which clients can ignore and mostly failed. HTTP/2 has been around for almost 10 years and I haven't seen a single implementation require it.

ttymck 3y ago

This is a result of trying to make HTTP "do everything well", right? Instead of leaving it to each application to select a layering of successive protocols tailored to it's needs, everything has been jammed into the HTTP spec, which has the nice property of giving you all its features in web browser clients (which is the delivery mechanism for this wide array of apps). Certainly some applications need not have access to the entire HTTP suite. If the goal is not to offer a "full-featured" client then an HTTP client may not be terribly difficult, it can just fail gracefully if the other party tries to do something it doesn't support?

raxxorraxor 3y ago

I will yell at the cloud too. I get why TypeScript exists. For large projects it really helps. But loosing one of the main benefits of scripting languages for some convenience? You could argue that you use webpack anyway. Same question applies here... If you have to use JS anyway, be glad that you can have an extremely shallow toolchain for deployment for smaller projects. I am not a JS dev, I just use it for stabbing at bits occasionally.