6 ms·

I don't know about this analogy. With websites, you're running the software locally. You just happened to download the software right before running it. Your ph

by baddox 9y ago

I don't know about this analogy. With websites, you're running the software locally. You just happened to download the software right before running it. Your phone's web browser is hardly "just a terminal," and in fact for most websites it probably requires significantly more processing power per user on the front end to render the site than it does on the backend to serve the data. Netflix might be a slightly better analogy, since it can naively be thought of as a dumb encoder just outputting a stream of data as it receives it.

throwanem 9y ago
In the 99%+ case for web apps, you're running only part of the software locally, and without the remote component the local part is useless. The distinction matters, especially when it comes to tasks like home automation - Nest alone is sufficient to exemplify the intractable problems that result from failing to design systems which perform purely local tasks in such a way that they require only local resources to do so. But Nest is far from alone in having so failed.
- baddox 9y ago
  > you're running only part of the software locally, and without the remote component the local part is useless. Of course that's true, but that's not sufficient for calling the client a terminal, unless you're going to define any client in a client-server architecture to be a terminal. Again, with most web apps or even simple web sites with static content, the processing power required to render and interact with the site is probably much greater than to serve data on the back end. Web browsers are definitely fat clients.
  - throwanem 9y ago
    > unless you're going to define any client in a client-server architecture to be a terminal Why not? As you say, the general-purpose computers we customarily use have much greater capability than the character or even graphics terminals of yore, but in the decidedly client-server architecture of most of the modern web, these general-purpose computers most certainly act as terminals nonetheless. (Some of the confusion here seems to arise from defining "terminal" at one point in terms of available compute resource, and at another point in terms of role within a distributed architecture. I'm not sure where the former makes sense - save in that it may constrain the roles in which a given device may be used, available resource seems entirely orthogonal to architecture.)
    - baddox 9y ago
      Why not? Well, simply because I'd prefer to use technical terms as they're widely used and widely understood. If someone wants to argue that the definitions themselves ought to change, then that's a semantic argument that doesn't interest me.
      - throwanem 9y ago
        The point I'm making about definitions is that the one you use here seems to vary within the space of a single comment.
    - deleted 9y ago
      [deleted]
camus2 9y ago
> I don't know about this analogy. With websites, you're running the software locally. The only thing most websites run locally is ad trackers which are of no value to the viewer. It's funny how the web didn't really fulfill its promise as a distribution platform for software, when Flash was doing that 15 years ago. Now i'm not saying there is no "photoshop","illustrator","premiere" or code IDE for the web right now. I'm saying it didn't perform as good as or replaced native apps. In that sense, the web failed.
TeMPOraL 9y ago
With websites (and web apps), you're only running UI locally. All the important parts - storage, queries, data wrangling, core logic - is done server-side.
- dan1234 9y ago
  This is the case with traditional websites, but web apps (especially Progressive Web Apps) are moving more and more of the heavy lifting back to the client.
  - simonh 9y ago
    And they key is that with the modern web architecture, having powerful local compute gives you the flexibility to put what can be usefully done on the server or on the client where it belongs. Terminal type architectures have no flexibility at all. Do round-trip times and bandwidth limitations mean this aspect of the application would be better done on the client? Tough. It has no computing power and isn't programmable so you don't even have the option. Want to manage tabs and bookmarks locally so you control that stuff instead of being beholden to the service suppliers? Tough, if the online service doesn't offer the feature to cannot have it because all the smarts is upstream.
Johnny555 9y ago
A web browser is similar to the old-style 3270 terminals too. All the mainframe server did was send bytes down to the terminal (well, terminal controller), the terminal itself would do all of the display formatting including field validation, then would send the user's data back up to the server. It's not quite the same since a web browser can run arbitrary code, but the browser is still used to display data to the user and return user's input to the server, while the back-end server does data storage and processing -- for example you wouldn't implement Google's search engine on client-side alone, all of the heavy lifting is done by Google's servers.
tarsinge 9y ago
Technically yes a lot of processing is done locally. But if you always need access to a service (i.e. a "powerful remote computer") to access your files, and if your device becomes useless without a connection to these services, then it kind of becomes a dumb terminal "philosophically"
- zeta0134 9y ago
  I think the only thing the quote gets wrong is the relative balance of power, as the assumption was that remote mainframes would always, due to size constraints, be more powerful than the terminals used to access them. Of course, the true power imbalance is connectivity, as it has always been. Using the internet is the primary reason most people own computers, and in that sense, our web browser has become our remote terminal. The computing tasks run on most sites doesn't require much more power than you could technically run locally, but the undeniable utility of connecting with other users makes the connection so valuable that the computer is, for most users, entirely useless without the internet.
  - TheOtherHobbes 9y ago
    This is very task-specific. For some reason lot of people seem to find it hard to imagine that there could be a mid-way system between the extremes of client/server - and that in fact the hybrid system is what we have today, where there's a genuine mix of local processing and storage for some tasks, with remote processing and storage for others. More, that the app economy is very much this hybrid, where users buy specific tools to do specific jobs locally, instead of running everything remotely, or independently programming applications from the ground up on their own hardware. Browsers are almost a side issue, because browsers are like a terminal, but only for a standard selection of popular applications - to some extent the lowest-common-denominator jobs that have the most utility for the widest demographics. Other jobs and applications still don't fit into the browser, and likely never will - even when there's a benefit to being able to collaborate. (E.g. I can't make music in my browser. If I want to collaborate I still have to send files over the Internet and wait for someone to edit them. Or I can use a mediocre collaboration system built into a DAW. But technically and socially, there are too many limitations to the in-browser experience to expect that live collaboration will become a thing soon.)

by baddox 9y ago

throwanem 9y ago

In the 99%+ case for web apps, you're running only part of the software locally, and without the remote component the local part is useless. The distinction matters, especially when it comes to tasks like home automation - Nest alone is sufficient to exemplify the intractable problems that result from failing to design systems which perform purely local tasks in such a way that they require only local resources to do so. But Nest is far from alone in having so failed.

baddox 9y ago
> you're running only part of the software locally, and without the remote component the local part is useless. Of course that's true, but that's not sufficient for calling the client a terminal, unless you're going to define any client in a client-server architecture to be a terminal. Again, with most web apps or even simple web sites with static content, the processing power required to render and interact with the site is probably much greater than to serve data on the back end. Web browsers are definitely fat clients.
- throwanem 9y ago
  > unless you're going to define any client in a client-server architecture to be a terminal Why not? As you say, the general-purpose computers we customarily use have much greater capability than the character or even graphics terminals of yore, but in the decidedly client-server architecture of most of the modern web, these general-purpose computers most certainly act as terminals nonetheless. (Some of the confusion here seems to arise from defining "terminal" at one point in terms of available compute resource, and at another point in terms of role within a distributed architecture. I'm not sure where the former makes sense - save in that it may constrain the roles in which a given device may be used, available resource seems entirely orthogonal to architecture.)
  - baddox 9y ago
    Why not? Well, simply because I'd prefer to use technical terms as they're widely used and widely understood. If someone wants to argue that the definitions themselves ought to change, then that's a semantic argument that doesn't interest me.
    - throwanem 9y ago
      The point I'm making about definitions is that the one you use here seems to vary within the space of a single comment.
  - deleted 9y ago
    [deleted]

camus2 9y ago

> I don't know about this analogy. With websites, you're running the software locally. The only thing most websites run locally is ad trackers which are of no value to the viewer. It's funny how the web didn't really fulfill its promise as a distribution platform for software, when Flash was doing that 15 years ago. Now i'm not saying there is no "photoshop","illustrator","premiere" or code IDE for the web right now. I'm saying it didn't perform as good as or replaced native apps. In that sense, the web failed.

TeMPOraL 9y ago

With websites (and web apps), you're only running UI locally. All the important parts - storage, queries, data wrangling, core logic - is done server-side.

dan1234 9y ago
This is the case with traditional websites, but web apps (especially Progressive Web Apps) are moving more and more of the heavy lifting back to the client.
- simonh 9y ago
  And they key is that with the modern web architecture, having powerful local compute gives you the flexibility to put what can be usefully done on the server or on the client where it belongs. Terminal type architectures have no flexibility at all. Do round-trip times and bandwidth limitations mean this aspect of the application would be better done on the client? Tough. It has no computing power and isn't programmable so you don't even have the option. Want to manage tabs and bookmarks locally so you control that stuff instead of being beholden to the service suppliers? Tough, if the online service doesn't offer the feature to cannot have it because all the smarts is upstream.

Johnny555 9y ago

A web browser is similar to the old-style 3270 terminals too. All the mainframe server did was send bytes down to the terminal (well, terminal controller), the terminal itself would do all of the display formatting including field validation, then would send the user's data back up to the server. It's not quite the same since a web browser can run arbitrary code, but the browser is still used to display data to the user and return user's input to the server, while the back-end server does data storage and processing -- for example you wouldn't implement Google's search engine on client-side alone, all of the heavy lifting is done by Google's servers.

tarsinge 9y ago

Technically yes a lot of processing is done locally. But if you always need access to a service (i.e. a "powerful remote computer") to access your files, and if your device becomes useless without a connection to these services, then it kind of becomes a dumb terminal "philosophically"

zeta0134 9y ago
I think the only thing the quote gets wrong is the relative balance of power, as the assumption was that remote mainframes would always, due to size constraints, be more powerful than the terminals used to access them. Of course, the true power imbalance is connectivity, as it has always been. Using the internet is the primary reason most people own computers, and in that sense, our web browser has become our remote terminal. The computing tasks run on most sites doesn't require much more power than you could technically run locally, but the undeniable utility of connecting with other users makes the connection so valuable that the computer is, for most users, entirely useless without the internet.
- TheOtherHobbes 9y ago
  This is very task-specific. For some reason lot of people seem to find it hard to imagine that there could be a mid-way system between the extremes of client/server - and that in fact the hybrid system is what we have today, where there's a genuine mix of local processing and storage for some tasks, with remote processing and storage for others. More, that the app economy is very much this hybrid, where users buy specific tools to do specific jobs locally, instead of running everything remotely, or independently programming applications from the ground up on their own hardware. Browsers are almost a side issue, because browsers are like a terminal, but only for a standard selection of popular applications - to some extent the lowest-common-denominator jobs that have the most utility for the widest demographics. Other jobs and applications still don't fit into the browser, and likely never will - even when there's a benefit to being able to collaborate. (E.g. I can't make music in my browser. If I want to collaborate I still have to send files over the Internet and wait for someone to edit them. Or I can use a mediocre collaboration system built into a DAW. But technically and socially, there are too many limitations to the in-browser experience to expect that live collaboration will become a thing soon.)