3 ms·

Aren't Single Page Applications implementing most of the ideas? Sending programs (Javascript), and objects (JSON). I think we moved already to very different fo

by _glass 4y ago

Aren't Single Page Applications implementing most of the ideas? Sending programs (Javascript), and objects (JSON). I think we moved already to very different formats than print, for better or worse, i.e. endless streams vs. a limited paper resource.

mike_hearn 4y ago
In the 80s/90s era that these ideas are rooted in, an "object" means both code and data fused together. In this worldview JSON is not a way to send objects despite the name, it's a way to send structs. In the sense Kay means, sending an object implies receiving a thing that implements one or more interfaces, on which you call methods/send messages, and then stuff happens. The data held by the object is encapsulated. What Java was trying to do with RMI, classloaders, etc was a lot closer to this vision because in that mechanism you could actually receive over the network a full object with both code and data, in which the actual underlying data structure was something you'd never seen before but it didn't matter as long as it implemented an interface you recognized, because the code to process the data came with it. This vision hit a number of practical engineering problems, most obviously security and less obviously the pervasive assumption of flat fast LAN-like networks that the CORBA/RMI/DCOM/etc people kept making. The web won out over this vision partly because it was simple enough to reimplement. When Tim Berners-Lee didn't have the resources to take it to the full potential (not even having proper inline images) NCSA Mosaic took over, then Netscape took over from them, then Microsoft from Netscape, then Chrome/Safari from Microsoft. The history of the web is basically a history of failed business models up until Google decides to just subsidize the whole thing in order to drive search traffic.
- pjmlp 4y ago
  Only to have anyone now use REST and gRPC for the same kind of purposes. The only major difference between what I was doing with RMI/CORBA and DCOM and now, is the tooling and the protocols. Everything else, IDL files, schemas, boilerplate generation, client SDK to wrap boilerplate code,.... is just the same story with a different dressing.
  - mike_hearn 4y ago
    Well yes, RPC systems are nothing but tooling and protocols so if those are the things that are different then everything changed ;) REST works because it's stateless message passing (no object state), supports one-way connectivity (no dialback), the tooling was much better (no equivalent in RMI/CORBA/DCOM to a transparent cache or a load balancer), HTTP/1.1 is easy to understand and implement (or looks easy at least) so every language can have get on the stack very fast, it has auth systems that work, it's more layered/incremental because it leaves language and type system mappings to higher layers, and so on. Lots of valid reasons.
    - pjmlp 4y ago
      A stateless message passing with statefull servers.... :)
dmitriid 4y ago
The core of the web is a system to display a page of static page with one or two images in a single rendering pass. SPAs etc. are insanely complicated and complex attempts to bend this into something it's not, and can never be. The reason people are so excited about WebGL and upcoming WebGPU is that they will be freed of constraints of this model (but forget about the constraints of doing low level graphics)
- bryanrasmussen 4y ago
  and forget about the constraints of legally mandated accessibility.
  - pjmlp 4y ago
    Most countries still don't have those kind of legal mandates. In all these years, accessibility has only been part of UAT for goverment related projects.
    - bryanrasmussen 4y ago
      https://ec.europa.eu/social/main.jsp?catId=1202 https://ec.europa.eu/social/main.jsp?catId=1202 sure it's true that most countries only have for government related projects, but that doesn't mean that there aren't enough important markets where that isn't the case.
      - pjmlp 4y ago
        EU directives are to be adopted as laws by the respective members, being a directive alone is not enough. As per experience, anything that isn't legally binding usually ends up not being part of project requirements.

by _glass 4y ago

mike_hearn 4y ago

In the 80s/90s era that these ideas are rooted in, an "object" means both code and data fused together. In this worldview JSON is not a way to send objects despite the name, it's a way to send structs. In the sense Kay means, sending an object implies receiving a thing that implements one or more interfaces, on which you call methods/send messages, and then stuff happens. The data held by the object is encapsulated. What Java was trying to do with RMI, classloaders, etc was a lot closer to this vision because in that mechanism you could actually receive over the network a full object with both code and data, in which the actual underlying data structure was something you'd never seen before but it didn't matter as long as it implemented an interface you recognized, because the code to process the data came with it. This vision hit a number of practical engineering problems, most obviously security and less obviously the pervasive assumption of flat fast LAN-like networks that the CORBA/RMI/DCOM/etc people kept making. The web won out over this vision partly because it was simple enough to reimplement. When Tim Berners-Lee didn't have the resources to take it to the full potential (not even having proper inline images) NCSA Mosaic took over, then Netscape took over from them, then Microsoft from Netscape, then Chrome/Safari from Microsoft. The history of the web is basically a history of failed business models up until Google decides to just subsidize the whole thing in order to drive search traffic.

pjmlp 4y ago
Only to have anyone now use REST and gRPC for the same kind of purposes. The only major difference between what I was doing with RMI/CORBA and DCOM and now, is the tooling and the protocols. Everything else, IDL files, schemas, boilerplate generation, client SDK to wrap boilerplate code,.... is just the same story with a different dressing.
- mike_hearn 4y ago
  Well yes, RPC systems are nothing but tooling and protocols so if those are the things that are different then everything changed ;) REST works because it's stateless message passing (no object state), supports one-way connectivity (no dialback), the tooling was much better (no equivalent in RMI/CORBA/DCOM to a transparent cache or a load balancer), HTTP/1.1 is easy to understand and implement (or looks easy at least) so every language can have get on the stack very fast, it has auth systems that work, it's more layered/incremental because it leaves language and type system mappings to higher layers, and so on. Lots of valid reasons.
  - pjmlp 4y ago
    A stateless message passing with statefull servers.... :)

dmitriid 4y ago

The core of the web is a system to display a page of static page with one or two images in a single rendering pass. SPAs etc. are insanely complicated and complex attempts to bend this into something it's not, and can never be. The reason people are so excited about WebGL and upcoming WebGPU is that they will be freed of constraints of this model (but forget about the constraints of doing low level graphics)

bryanrasmussen 4y ago
and forget about the constraints of legally mandated accessibility.
- pjmlp 4y ago
  Most countries still don't have those kind of legal mandates. In all these years, accessibility has only been part of UAT for goverment related projects.
  - bryanrasmussen 4y ago
    https://ec.europa.eu/social/main.jsp?catId=1202 https://ec.europa.eu/social/main.jsp?catId=1202 sure it's true that most countries only have for government related projects, but that doesn't mean that there aren't enough important markets where that isn't the case.
    - pjmlp 4y ago
      EU directives are to be adopted as laws by the respective members, being a directive alone is not enough. As per experience, anything that isn't legally binding usually ends up not being part of project requirements.