4 ms·

Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over. So, here we have the return of the fat client, epis

by moe 17y ago

Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over. So, here we have the return of the fat client, episode 20. And as with all the other episodes the standard question remains: If you're going fat-client then why on earth stick to a platform as horrible as HTML/JS?

rcoder 17y ago
The reasons to stick with DHTML/JS as a "thick client" development platform are simple: decent, free development tools, the ability to interpose proxies and application middleware between the client and server transparently, and a very, very large install base for the client runtime. That being said, I share much of your amusement at/disdain for the attitude of "OMG, look at this brand new thing I have made that is completely different from all those old things!"
- moe 17y ago
  I'm not sure about these reasons. decent, free development tools Well, you can have these for any mature platform. Be it QT, Flex or even Java. I'm not sure what's more decent about the HTML toolchain. The often cited FireBug is, to me, merely an emergency bandaid that makes development at least possible but still far from enjoyable. the ability to interpose proxies and application middleware between the client and server transparently There's nothing stopping any fat-client to speak HTTP. You don't need to a browser for that. and a very, very large install base for the client runtime. I'd say installation base is a red herring when talking about cross-platform apps but I'll give you that "instant-on" is an argument. For that I'd point to Air, which can run hybrid in and outside the browser. I'm not arguing that HTML doesn't have it's place, mind you. But the extent to which it is abused nowadays is absurd.
  - shabda 17y ago
    > and a very, very large install base for the client runtime. You are underetimating this. For evrything else, (air, java, Qt, C#) I have to start a new app. My firefox is always on.
    - johnpaulett 17y ago
      In most cases, we are just swapping some startup time (for java, qt, etc.) for download time in the heavy web 2.0 apps.
- omouse 17y ago
  Tools for developing Qt and Java applications are also free and are much much better than anything that has been created for DHTML/JS so far. Java too has a very large install base. It is a shame that SUN didn't do much to promote it but you can still take advantage of the fact that many many people have the JVM installed.
sjs 17y ago
Modern standards compliant browsers are usually cross-platform so HTML is the new GUI toolkit, scripted by JS. Especially with WebGL and O3D in the works we will see the browser become the delivery mechanism for the new-old-school fat client. The difference between the new and old is network awareness. New style apps are often mashups. Programs are temporarily installed for a session by visiting a specific URL (Chrome's app shortcut even makes it seem like a real installation). You update to new versions by refreshing the page. Old school, new school, like it or not, this is the foreseeable future.
- moe 17y ago
  Especially with WebGL and O3D in the works we will see the browser become the delivery mechanism for the new-old-school fat client. I'm sorry but I fail to see what 3d technology in the browser has to do with application UIs. The two fundamental problems with HTML are the complete failure that is the box model, and the W3Cs complete ignorance of real world requirements. As an example for the latter just look at the pityful HTML widget-set that hasn't changed one bit over the last 15 years. Every OS GUI toolkit in existence has native widgets for comboboxes, date pickers, sliders and various other amazingly useful primitives. I don't see any plans for finally bringing any of that to HTML. Instead we'll continue to see every new javascript framework reinvent them to varying degrees of success, along with a long list of other baseline functionality (client-side form validation, anyone? WebSocket really soon now?). All the while the W3C invents fancy audio/video tags, 3d widgets, a questionable canvas API and lots of other stuff that hardly solves any real problem we developers are fighting every day, in any app. I don't think the evolution of RIAs will wait for the W3C to get their act together. I rather think the alternatives to the browser will see a raise in popularity in the foreseeable future, as the HTML/JS combo gets maxed out and more people start looking for ways to notch the expirience up further than possible within the browser constraints...
tewks 17y ago
There is an important aspect that not many "fat clients" have solved except the iPhone (except for the fact many iPhone apps are pirated and end up torrented): a reliable way to charge users... 50% of Photoshop installs are pirated; I wonder how many users of Salesforce are using pirated copies?
iamwil 17y ago
I hear all the negatives of why it wouldn't work, and everything that's wrong with it. And it's certainly healthy to be skeptical. But I don't hear anyone talking about what its possibilities are. While it might be the new old thing, it's happening in the context of a different tech env, different market. The limitations of the old old thing might be different for the new old thing.
flogic 17y ago
Well in this case the client side isn't the interesting part. The interesting part is the compaction of the server part into the database. The one language to rue them all is also interesting to a point but I assume you can do that with a Java app too.
- awt 17y ago
  I can see productivity gains in that more can be done without messing with a server side web framework, so there could be less maintenance.
ahpeeyem 17y ago
Because the HTML/JS platform is only getting nicer. Almost everyone is already dumping fat clients for web clients, even in the enterprise, and it started way before AJAX was even heard of. The advantages of a fat-client client/server app are low latency of the UI, maybe development speed given the right toolset, plus definitely flexibility of the UI for graphics and complicated interactions. Disadvantages though are difficulty of deployment, client platform restrictions, distributing updates/patches. Whereas the traditional web thin client is easy deployment to your users across different platforms, via your single installation on the server. The disadvantage of traditional web clients is that you're restricted in UI complexity and latency is high. But this hasn't stopped so many enterprise and web apps being written (and rewritten) for the web, just to get deployment/update simplicity in place of a fat client. So if you can build a complex UI fat client with low latency and the deployment ease of a web app, you're having your cake and eating it too. I think it really could be different, this time.
eob 17y ago
My thoughts exactly.

by moe 17y ago

rcoder 17y ago

The reasons to stick with DHTML/JS as a "thick client" development platform are simple: decent, free development tools, the ability to interpose proxies and application middleware between the client and server transparently, and a very, very large install base for the client runtime. That being said, I share much of your amusement at/disdain for the attitude of "OMG, look at this brand new thing I have made that is completely different from all those old things!"

moe 17y ago
I'm not sure about these reasons. decent, free development tools Well, you can have these for any mature platform. Be it QT, Flex or even Java. I'm not sure what's more decent about the HTML toolchain. The often cited FireBug is, to me, merely an emergency bandaid that makes development at least possible but still far from enjoyable. the ability to interpose proxies and application middleware between the client and server transparently There's nothing stopping any fat-client to speak HTTP. You don't need to a browser for that. and a very, very large install base for the client runtime. I'd say installation base is a red herring when talking about cross-platform apps but I'll give you that "instant-on" is an argument. For that I'd point to Air, which can run hybrid in and outside the browser. I'm not arguing that HTML doesn't have it's place, mind you. But the extent to which it is abused nowadays is absurd.
- shabda 17y ago
  > and a very, very large install base for the client runtime. You are underetimating this. For evrything else, (air, java, Qt, C#) I have to start a new app. My firefox is always on.
  - johnpaulett 17y ago
    In most cases, we are just swapping some startup time (for java, qt, etc.) for download time in the heavy web 2.0 apps.
omouse 17y ago
Tools for developing Qt and Java applications are also free and are much much better than anything that has been created for DHTML/JS so far. Java too has a very large install base. It is a shame that SUN didn't do much to promote it but you can still take advantage of the fact that many many people have the JVM installed.

sjs 17y ago

Modern standards compliant browsers are usually cross-platform so HTML is the new GUI toolkit, scripted by JS. Especially with WebGL and O3D in the works we will see the browser become the delivery mechanism for the new-old-school fat client. The difference between the new and old is network awareness. New style apps are often mashups. Programs are temporarily installed for a session by visiting a specific URL (Chrome's app shortcut even makes it seem like a real installation). You update to new versions by refreshing the page. Old school, new school, like it or not, this is the foreseeable future.

moe 17y ago
Especially with WebGL and O3D in the works we will see the browser become the delivery mechanism for the new-old-school fat client. I'm sorry but I fail to see what 3d technology in the browser has to do with application UIs. The two fundamental problems with HTML are the complete failure that is the box model, and the W3Cs complete ignorance of real world requirements. As an example for the latter just look at the pityful HTML widget-set that hasn't changed one bit over the last 15 years. Every OS GUI toolkit in existence has native widgets for comboboxes, date pickers, sliders and various other amazingly useful primitives. I don't see any plans for finally bringing any of that to HTML. Instead we'll continue to see every new javascript framework reinvent them to varying degrees of success, along with a long list of other baseline functionality (client-side form validation, anyone? WebSocket really soon now?). All the while the W3C invents fancy audio/video tags, 3d widgets, a questionable canvas API and lots of other stuff that hardly solves any real problem we developers are fighting every day, in any app. I don't think the evolution of RIAs will wait for the W3C to get their act together. I rather think the alternatives to the browser will see a raise in popularity in the foreseeable future, as the HTML/JS combo gets maxed out and more people start looking for ways to notch the expirience up further than possible within the browser constraints...

tewks 17y ago

There is an important aspect that not many "fat clients" have solved except the iPhone (except for the fact many iPhone apps are pirated and end up torrented): a reliable way to charge users... 50% of Photoshop installs are pirated; I wonder how many users of Salesforce are using pirated copies?

iamwil 17y ago

I hear all the negatives of why it wouldn't work, and everything that's wrong with it. And it's certainly healthy to be skeptical. But I don't hear anyone talking about what its possibilities are. While it might be the new old thing, it's happening in the context of a different tech env, different market. The limitations of the old old thing might be different for the new old thing.

flogic 17y ago

Well in this case the client side isn't the interesting part. The interesting part is the compaction of the server part into the database. The one language to rue them all is also interesting to a point but I assume you can do that with a Java app too.

awt 17y ago
I can see productivity gains in that more can be done without messing with a server side web framework, so there could be less maintenance.

ahpeeyem 17y ago

Because the HTML/JS platform is only getting nicer. Almost everyone is already dumping fat clients for web clients, even in the enterprise, and it started way before AJAX was even heard of. The advantages of a fat-client client/server app are low latency of the UI, maybe development speed given the right toolset, plus definitely flexibility of the UI for graphics and complicated interactions. Disadvantages though are difficulty of deployment, client platform restrictions, distributing updates/patches. Whereas the traditional web thin client is easy deployment to your users across different platforms, via your single installation on the server. The disadvantage of traditional web clients is that you're restricted in UI complexity and latency is high. But this hasn't stopped so many enterprise and web apps being written (and rewritten) for the web, just to get deployment/update simplicity in place of a fat client. So if you can build a complex UI fat client with low latency and the deployment ease of a web app, you're having your cake and eating it too. I think it really could be different, this time.

eob 17y ago

My thoughts exactly.