5 ms·

It can hardly be a "prerequisite" given that most web applications built to date have managed to do without it. It's a convenience, at least intuitively, but i

It can hardly be a "prerequisite" given that most web applications built to date have managed to do without it. It's a convenience, at least intuitively, but in practice one has to wonder what parts of your code run in both browser and server and do async I/O.

jorangreef 16y ago
Firstly, most web applications to date do not: 1. Work offline. 2. Provide sub-20ms interface switching response rates. 3. Protect the interface against extended network or server failure. 4. Buffer against poor network performance. So I would agree with you that they have "managed to do without it" (code-sharing) so far. But they have done so only by avoiding responsibility for these goals, by considering them a convenience, or by not considering them at all. Secondly, I can tell you from experience that a non-Javascript server-side framework can do the above but only with difficulty. Existing popular frameworks do not provide "convention-over-configuration" assistance in terms of straddling the network or exposing Model definitions to Javascript etc. They render interfaces on the server-side, rather than letting controllers and views interact on the client for example. Indeed it would not even be fair to expect these frameworks to meet the above requirements, simply because they were not designed to do so. Eventually one must arrive at a realization that web applications (as distinct from "web sites") will mostly be written in the same language AND framework on both client and server. Fear not, this will probably be more fun.
- allertonm 16y ago
  I simply do not see why your goals 1-4 require a) the same language on the server as the client and b) the use of a non-blocking I/O model at the server. It appears to be a leap of faith on your part. While marshalling of model objects to JSON is obviously going to be easier to achieve if your model objects are Javascript objects, marshalling to JSON is trivially achieveable in almost all programming languages. To suggest that developers should - to achieve this microscopic payoff - choose to build servers using a language with a crippled concurrency model (i.e none) is laughable.
  - jorangreef 16y ago
    Re: "I simply do not see why your goals 1-4 require a) the same language on the server as the client" Have you ever done 1-4? Re: "marshalling to JSON is trivially achieveable in almost all programming languages" Code sharing and JSON serialization/deserialization are not the same thing. Re: "To suggest that developers should - to achieve this microscopic payoff - choose to build servers using a language with a crippled concurrency model (i.e none) is laughable." Ships will sail around the Earth but the Flat Earth Society will continue to flourish.

jorangreef 16y ago

Firstly, most web applications to date do not: 1. Work offline. 2. Provide sub-20ms interface switching response rates. 3. Protect the interface against extended network or server failure. 4. Buffer against poor network performance. So I would agree with you that they have "managed to do without it" (code-sharing) so far. But they have done so only by avoiding responsibility for these goals, by considering them a convenience, or by not considering them at all. Secondly, I can tell you from experience that a non-Javascript server-side framework can do the above but only with difficulty. Existing popular frameworks do not provide "convention-over-configuration" assistance in terms of straddling the network or exposing Model definitions to Javascript etc. They render interfaces on the server-side, rather than letting controllers and views interact on the client for example. Indeed it would not even be fair to expect these frameworks to meet the above requirements, simply because they were not designed to do so. Eventually one must arrive at a realization that web applications (as distinct from "web sites") will mostly be written in the same language AND framework on both client and server. Fear not, this will probably be more fun.

allertonm 16y ago
I simply do not see why your goals 1-4 require a) the same language on the server as the client and b) the use of a non-blocking I/O model at the server. It appears to be a leap of faith on your part. While marshalling of model objects to JSON is obviously going to be easier to achieve if your model objects are Javascript objects, marshalling to JSON is trivially achieveable in almost all programming languages. To suggest that developers should - to achieve this microscopic payoff - choose to build servers using a language with a crippled concurrency model (i.e none) is laughable.
- jorangreef 16y ago
  Re: "I simply do not see why your goals 1-4 require a) the same language on the server as the client" Have you ever done 1-4? Re: "marshalling to JSON is trivially achieveable in almost all programming languages" Code sharing and JSON serialization/deserialization are not the same thing. Re: "To suggest that developers should - to achieve this microscopic payoff - choose to build servers using a language with a crippled concurrency model (i.e none) is laughable." Ships will sail around the Earth but the Flat Earth Society will continue to flourish.