4 ms·

The "sane" thing to do is to complicate the protocol by building it on top of both SCTP _and_ UDP? How is it the "sane" thing to do to make the protocol more co

The "sane" thing to do is to complicate the protocol by building it on top of both SCTP _and_ UDP? How is it the "sane" thing to do to make the protocol more complicated with a fallback that easily allows the middleboxes to just ignore the SCTP option knowing that UDP will work? That wouldn't have accomplished anything, except re-affirming that middleboxes tend to reject SCTP at rates that make it unrealistic to adopt it at scale. What they did accomplish, however, is getting an open protocol to the IETF for adoption that works on the actual internet. I fail to see how that is some sort of conspiracy or incompetence. And that isn't even taking into account that building on top of SCTP would have made some of QUIC's goals hard / impossible such as eliminating the penalty for establishing encrypted connections - something which benefits the internet at large. What open protocols / standards duplicate WebSockets, WebRTC, or WebAssembly? TCP is kinda like WebSockets - but, giving any random JavaScript the ability to open TCP connections is a bad idea - nevermind that WebSockets provides are variety of useful abstractions such as messages. I'm not sure what you are saying duplicates WebRTC - there are a bunch of proprietary protocols, I guess, but, I'm not aware of anything open that its competing with. As for WebAssembly, it explicitly works with JavaScript providing significant efficiencies for certain types of code. Google, Microsoft, etc have their faults. But, picking out instances of when they have worked together, in the open, to create free, open standards that benefit everyone to complain about is just super bizarre.

wtallis 8y ago
> What open protocols / standards duplicate WebSockets, WebRTC, or WebAssembly? Those aren't duplicating open protocols, they're just re-inventing the operating system inside the web browser, but with more overhead and fewer features and generally not even working as well as Java. The Web-* standards just make it possible to do things inside the browser that are already possible outside the browser, and are a bad idea to do inside the browser. Their only advantage is that it makes it a bit easier for the developer to deliver the "application", but it usually also results in the developer leaving out a lot of functionality and refinement that a native application would have.
- dagenix 8y ago
  WebRTC isn't even working as well as Java? I guess thats hard to argue with because it makes no sense.
  - wtallis 8y ago
    I feel like you aren't even trying to understand what this conversation is about. The analogy between Java and the Web-* technologies is pretty obvious, unless you want to pretend you've never encountered the phrase "write once, run anywhere". Java was at least constructed from the start with the intention of hosting full-featured applications and giving them access to things like low-level networking APIs while providing a high-performance JIT environment. All of that functionality is being grafted piecemeal onto JavaScript to bring the browser up to the same level of capability, but this time the tradeoffs are even more severe. The browser can now provide an application platform that approaches the capabilities of something like Java when viewed at a high level, but it's even worse at providing good usability (particularly in the areas of integration with the host OS and accessibility), still can't match the feature set of the Java ecosystem, makes it almost impossible to interface with existing code that wasn't written to run in the browser, and makes it harder to achieve good performance. I don't even like Java, but at least I can recognize that it's a more mature solution to the same general problem, and Java doesn't try as hard to ignore the hard parts of cross-platform development. The past decade of scope creep within browsers can be summarized as: providing mediocre solutions to problems that already have widely available good solutions.
    - dagenix 8y ago
      > I feel like you aren't even trying to understand what this conversation is about. Thank you for being condescending. > The analogy between Java and the Web-* technologies is pretty obvious, unless you want to pretend you've never encountered the phrase "write once, run anywhere". What does that phrase have to do with anything? And saying that Java (a platform) is somehow an analogy for "Web-*" technologies is a bit of a stretch (to be generous). They aren't even in the same category - for example, Java is a language / runtime / platform; WebRTC is a protocol. You can implement the latter on the former, but not the other way around. Native apps aren't dead - they are still doing fine. There are a number of benefits to creating browser based apps - such as the ease of getting them and getting updates - that tend to be harder / lengthier for native apps. There are a bunch of benefits to native apps. We live in a world where its ok for people to improve both experiences.

wtallis 8y ago

> What open protocols / standards duplicate WebSockets, WebRTC, or WebAssembly? Those aren't duplicating open protocols, they're just re-inventing the operating system inside the web browser, but with more overhead and fewer features and generally not even working as well as Java. The Web-* standards just make it possible to do things inside the browser that are already possible outside the browser, and are a bad idea to do inside the browser. Their only advantage is that it makes it a bit easier for the developer to deliver the "application", but it usually also results in the developer leaving out a lot of functionality and refinement that a native application would have.

dagenix 8y ago
WebRTC isn't even working as well as Java? I guess thats hard to argue with because it makes no sense.
- wtallis 8y ago
  I feel like you aren't even trying to understand what this conversation is about. The analogy between Java and the Web-* technologies is pretty obvious, unless you want to pretend you've never encountered the phrase "write once, run anywhere". Java was at least constructed from the start with the intention of hosting full-featured applications and giving them access to things like low-level networking APIs while providing a high-performance JIT environment. All of that functionality is being grafted piecemeal onto JavaScript to bring the browser up to the same level of capability, but this time the tradeoffs are even more severe. The browser can now provide an application platform that approaches the capabilities of something like Java when viewed at a high level, but it's even worse at providing good usability (particularly in the areas of integration with the host OS and accessibility), still can't match the feature set of the Java ecosystem, makes it almost impossible to interface with existing code that wasn't written to run in the browser, and makes it harder to achieve good performance. I don't even like Java, but at least I can recognize that it's a more mature solution to the same general problem, and Java doesn't try as hard to ignore the hard parts of cross-platform development. The past decade of scope creep within browsers can be summarized as: providing mediocre solutions to problems that already have widely available good solutions.
  - dagenix 8y ago
    > I feel like you aren't even trying to understand what this conversation is about. Thank you for being condescending. > The analogy between Java and the Web-* technologies is pretty obvious, unless you want to pretend you've never encountered the phrase "write once, run anywhere". What does that phrase have to do with anything? And saying that Java (a platform) is somehow an analogy for "Web-*" technologies is a bit of a stretch (to be generous). They aren't even in the same category - for example, Java is a language / runtime / platform; WebRTC is a protocol. You can implement the latter on the former, but not the other way around. Native apps aren't dead - they are still doing fine. There are a number of benefits to creating browser based apps - such as the ease of getting them and getting updates - that tend to be harder / lengthier for native apps. There are a bunch of benefits to native apps. We live in a world where its ok for people to improve both experiences.