23 ms·

(ugh, right? How last century) Its not really about a "last century" thing, "last century" most apps need not multiple front-ends like today, unless you are 10

(ugh, right? How last century) Its not really about a "last century" thing, "last century" most apps need not multiple front-ends like today, unless you are 100% you won't need multiple front-ends, doing a json api from the start simplifies things a lot.

aaronbrethorst 12y ago
I was being a smartass :) unless you are 100% you won't need multiple front-ends, doing a json api from the start simplifies things a lot. This also presumes that I already know Backbone, Ember, React, Knockout, Batman, Angular, or whichever new JS single page app frameworks have appeared in the last 30 seconds. Would you agree that it's easier[1] to write a web app that emits HTML than it is to write a web app that emits JSON which is consumed by a single page web app written in Javascript? [1] Where I define "easier" in this context to mean requiring less wall clock time to get something showing up on-screen and doing something useful.
- mbell 12y ago
  You don't have to use a JS MVC framework just because you built your core logic behind a JSON API. You can just as easily have a server side rendering app talk to the JSON API instead of the directly to the datastores. You get to stick with 'what you know' while still maintaining flexibility for later.
  - Scarbutt 12y ago
    yes, but it will more complex and take up more time, which I think is what he is talking about.
nostrademons 12y ago
Last century most apps absolutely did need multiple front-ends. Don't you remember the days when there was a Windows version, a Mac version, a Java version, if you were lucky a Linux version, and maybe a web version for the bleeding-edge developers? Relatively fewer apps were network-enabled, but even then, there were a bunch of technologies like CORBA, DCOM, and RMI to marshal communications. There were also a bunch of custom binary protocols; back then, it was common for software developers to work on all levels of the stack, and the culture of library re-use was not as entrenched (at least in the enterprise) as it is today.

aaronbrethorst 12y ago

I was being a smartass :) unless you are 100% you won't need multiple front-ends, doing a json api from the start simplifies things a lot. This also presumes that I already know Backbone, Ember, React, Knockout, Batman, Angular, or whichever new JS single page app frameworks have appeared in the last 30 seconds. Would you agree that it's easier[1] to write a web app that emits HTML than it is to write a web app that emits JSON which is consumed by a single page web app written in Javascript? [1] Where I define "easier" in this context to mean requiring less wall clock time to get something showing up on-screen and doing something useful.

mbell 12y ago
You don't have to use a JS MVC framework just because you built your core logic behind a JSON API. You can just as easily have a server side rendering app talk to the JSON API instead of the directly to the datastores. You get to stick with 'what you know' while still maintaining flexibility for later.
- Scarbutt 12y ago
  yes, but it will more complex and take up more time, which I think is what he is talking about.

nostrademons 12y ago

Last century most apps absolutely did need multiple front-ends. Don't you remember the days when there was a Windows version, a Mac version, a Java version, if you were lucky a Linux version, and maybe a web version for the bleeding-edge developers? Relatively fewer apps were network-enabled, but even then, there were a bunch of technologies like CORBA, DCOM, and RMI to marshal communications. There were also a bunch of custom binary protocols; back then, it was common for software developers to work on all levels of the stack, and the culture of library re-use was not as entrenched (at least in the enterprise) as it is today.