Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Long Death of Fat Clients

samzenpus posted about 2 years ago | from the slimming-down dept.

Programming 277

snydeq writes "With Adobe's divestment of Flex and mobile Flash and Microsoft's move from Silverlight to Metro, Oracle now seems all alone in believing that a fat client framework — in the form of JavaFX — is a worthwhile investment, writes Andrew Oliver. 'Fewer and fewer options exist for developing purely fat client desktop applications and fewer still for RAD applications with Web-based delivery (aka, "thick clients"). We are on the verge of a purely HTML/JavaScript client world. Or we would be, if it weren't for mobile pushing us back to client-side development.'"

cancel ×


Um... (5, Insightful)

Anonymous Coward | about 2 years ago | (#40483937)

Isn't this whole HTML 5 business basically Browsers becoming fat clients, by your definition?

Re:Um... (5, Insightful)

Johann Lau (1040920) | about 2 years ago | (#40484227)

Yeah, but *heavily* crippled ones.

28c3: The coming war on general computation []

Re:Um... (2, Interesting)

cpu6502 (1960974) | about 2 years ago | (#40484613)

I can't watch youtube at work. Is there a text version of this?

I like the old "plugin" model of web browsers. If you want to see a JPEG, install JPEGview. If you want to hear an MP3 or AIFF, install a player. Over time though I guess all these plugins have been buried inside the browser code. Now the browser is expected to do it all automatically in one large massive program that eats a gigabyte of RAM.

Re:Um... (4, Insightful)

fermat1313 (927331) | about 2 years ago | (#40484983)

I can't watch youtube at work. Is there a text version of this?

I like the old "plugin" model of web browsers. If you want to see a JPEG, install JPEGview. If you want to hear an MP3 or AIFF, install a player. Over time though I guess all these plugins have been buried inside the browser code. Now the browser is expected to do it all automatically in one large massive program that eats a gigabyte of RAM.

If someone came out with a browser out of the box that could only display HTML text with no pictures, sound, etc, do you really think it would get enough use to become traction? Images, sound and video are part of the modern day web browsing experience for the vast majority of users. It's time to get over the origins of the web as a text-only system

Also, most browsers do have the capability for plug-ins, which meets some of your needs. Ultimately, though, plug-ins present their own privacy and security concerns (think Flash). I'd rather have my basic services provided by a trusted vendor with the resources to properly test their software and with a reputation I can trust.

Re:Um... (1, Insightful)

Anonymous Coward | about 2 years ago | (#40485047)

Mod parent up. It's worth the read (2)

djl4570 (801529) | about 2 years ago | (#40485993)

Great analogy.

If I wanted Congress, Parliament, or the E.U. to regulate a wheel, it's unlikely I'd succeed. If I turned up, pointed out that bank robbers always make their escape on wheeled vehicles, and asked, “Can't we do something about this?", the answer would be “No".

Re:Um... (2)

w.hamra1987 (1193987) | about 2 years ago | (#40485757)

compile your own firefox, without the built-in libraries

Re:Um... (0, Flamebait)

Anonymous Coward | about 2 years ago | (#40485805)

At the end of the day no browser based trickery comes close to the performance and options you have available on even a hastily clobbed together C# app. Never mind the classic languages.

Re:Um... (3, Interesting)

foniksonik (573572) | about 2 years ago | (#40485943)

Would you want to download and install every web based app you use to your desktop? How about every commerce site?

Just asking. Actually want to know.

Re:Um... (4, Insightful)

Old97 (1341297) | about 2 years ago | (#40484291)

Exactly. "Fat" doesn't refer to the footprint as much as it does the proportion of the workload executed in the client. A thin client renders and perhaps it formats, but does it also maintain state? If it does (e.g. HTML5) or you rely on it to do a lot of cross-field validations then I'd say your client is getting "fatter". Its a continuum, but if you lose enough hair at some point we will all agree that you are bald.

Re:Um... (0, Offtopic)

bobcat7677 (561727) | about 2 years ago | (#40485787)

Much like my women, I like my clients to have a little substance to them.

Re:Um... (5, Interesting)

mcgrew (92797) | about 2 years ago | (#40484457)

Isn't this whole HTML 5 business basically Browsers becoming fat clients, by your definition?

They want all your data on their servers is why they keep pusing the "fat client is dead" meme. I doubt they'll ever give up; just like Intel was soundly trounced for suggesting something like UEFI fifteen years ago, followed by Microsoft being soundly trounced for Palladium (UEFI ten yeras ago), and now they're still at at, the bastards.

The "fat client is dead, the cloud is better!" bullshit is no different. They want to control YOUR computer and YOUR data.

Rise up and fight this absurd madness!

What's worse is the "phone apps are making phones fat clients." No, what's making phones "fat clients" is the same thing as making your PC a thin client -- their desire for control over your data. "Want to listen to our radio station on your Android or iPhone? We have an app for that!" when a simple web page served to your browser should work. Point your phone's browser to WQNA [] and click the aac or mp3 link, you should hear them on your phone. Why can't other stations do that? (BTW, in about five hours they'll be playing ska and raggae; it's a local college station that you can never be sure what genre is going to be played. I once heard Johnny Cash followed by the Dead Kennedies on that station).

If the data is coming from the internet, like a radio stream, you should need no app. When your data is produced locally, you should need no internet.

Why are we letting these people from Bizarro World fuck everything up, anyway?

Re:Um... (5, Insightful)

icebraining (1313345) | about 2 years ago | (#40485791)

"Letting" them? What exactly do you propose? That we set their offices on fire because they make apps instead of websites?

They want control over the experience and data, and most people do not want control over their own experience and data. You can warn about the current and potential dangers, but otherwise it's their stuff, if they want to give it away, who are we to decide otherwise?

Re:Um... (5, Insightful)

CubicleZombie (2590497) | about 2 years ago | (#40485203)

I'm currently working on a large JavaScript based application. It's just like every rich client I've ever done, except it's not type safe, or compile safe. Debugging is a pain in the ass. It's slower. I have to make it work in multiple browsers. It's enterprisey and web 2.0ish and pretty, but missing all the powerful UI tools I have under .NET or Swing. As a developer, It just seems like a huge step backwards.

Re:Um... (1)

Bucc5062 (856482) | about 2 years ago | (#40485783)

Thank you!!! I feel the same way. Program development in a browser was never fully fleshed out, but brought to us in pieces and we get to try and "make it work". I love that smartphone apps are really nothing but shrunk down desktop apps just more function specific. Web development is kuldgy and limited, because of the browser and while it allows "cross platform" execution, we code to the lowest denominator.

Re:Um... (4, Informative)

icebraining (1313345) | about 2 years ago | (#40485893)

So? Machine code isn't typed either. Much like for native applications, you can use a statically (and strongly) typed language and compile it down to JavaScript.

List of languages that compile to JavaScript [] .

Mobile would go thin too... (1)

GameboyRMH (1153867) | about 2 years ago | (#40483949)

...if there were enough bandwidth to do everything server-side ("TEH CLOUD" as the marketroids call it these days) ChromeOS is on that track. Plus then the platform vendor could have even more control over what software you run and what content you put on your device, plus a convenient excuse for total data collection - it has to go through them, that's how it works!

Yay. (2, Interesting)

axlr8or (889713) | about 2 years ago | (#40483953)

Here I sit. On a computer with 3 versions of Java. And it is very, very confused. And, this is what I expect of Java. Weighty, slow. It's cross platform implementation is the only reason I like it. Other than that, its a resource consuming behemoth that just rings up as another diversion for how many years? As a user it's always been trouble with policy changes and updates. It's making my browser have fits. So, fat or thin, thick or emaciated I don't care much for Java. I know I don't know as much about it as you guys do.

Re:Yay. (3, Informative)

GameboyRMH (1153867) | about 2 years ago | (#40484009)

Assuming you're running Windows just remove the older versions, newer installers do it automatically but if you have some REALLY old versions on there you'll have to remove them yourself.

If you're running Linux, well it's your choice to run Sun Java, OpenJDK and...whatever other Java RE you've found, at the same time.

Re:Yay. (4, Insightful)

Dog-Cow (21281) | about 2 years ago | (#40484059)

You are assuming that all his software is compatible with the latest version. That is often not the case. With Java.

Re:Yay. (1, Insightful)

Yetihehe (971185) | about 2 years ago | (#40484235)

I haven't yet found a program which stopped working with newer java.

Re:Yay. (4, Informative)

benf_2004 (931652) | about 2 years ago | (#40484307)

I haven't yet found a program which stopped working with newer java.

Up until last month, we still had to install Java 1.5 on some users' computers because their jobs required them to use a web application that would not work on Java 1.6 or newer. We neither develop nor host the application, so all we could do was keep installing the horribly outdated version of Java and wait for the application to be upgraded to work with Java 1.6.

Re:Yay. (1)

Yetihehe (971185) | about 2 years ago | (#40484479)

Interesting. Have you seen many such apps? Could you tell me which app it was?

Re:Yay. (1)

Anonymous Coward | about 2 years ago | (#40485183)

Interesting. Have you seen many such apps? Could you tell me which app it was?

Here's one real example for you: Entrust Truepass [] , which is an enterprise platform which allegedly makes internet transactions super secure. It's a POS. The user has to run java in their web browser for it to work.

When java 1.6u29 came out, all Entrust Truepass applications stopped dead. Unfortunately, Entrust Truepass has spread to many websites, including:

Government of Canada: []

Lowes purchasing with vendors: []

US Patent Office: []

And many others, including some banks. The only solutions were:

- run an old version of java with well documented easy-to-exploit security holes while carrying out important transactions
- don't use Entrust Truepass

Given that Entrust Truepass is marketed to businesses interested in security, neither option is acceptable.

Eventually Entrust Truepass fixed their java crapplets, but you really should move to a normal web app that doesn't depend on java.

Re:Yay. (2, Informative)

Bigby (659157) | about 2 years ago | (#40485309)

This is probably because of a security flaw that u29 closed and Entrust Truepass utilized to function. That isn't the fault of the compile code, but the security manager. This can be resolved through a change in the java.policy file.

Sometimes the problem comes up because someone used a Sun/Oracle class or an IBM class instead of the standard API.

Re:Yay. (0)

Anonymous Coward | about 2 years ago | (#40485263)

Oracle Forms are not compatible with Java 1.7, you have to use an earlier version.

Re:Yay. (1)

Dewin (989206) | about 2 years ago | (#40484643)

I've read that Maptools [] (an open-source virtual tabletop for RPGs/etc.) currently is non-functional under Java 7, presumably due to an incompatible library.

Re:Yay. (0)

Anonymous Coward | about 2 years ago | (#40484709)

First one to come to mind was Cisco PIX. Royal PITA!

Re:Yay. (1)

vux984 (928602) | about 2 years ago | (#40484881)

The RBC bank site recently required you to have a previous version installed. It was finally resolved a few months ago.

I also have a cisco router where its internal web admin stuff didn't work with a modern java.

Re:There are tons (1)

Billly Gates (198444) | about 2 years ago | (#40484995)

They are mostly enterprise web apps.

If you know anyone who works in finance all the big banks use Java that require particular versions to do corporate banking. This is not the same Bank of America we get to check out accountants but rather ones that deal with complex stuff like investments, lines of credit, investing etc. Almost everyone uses manpower or Kronos to clock hourly employees in and out and to process payroll for HR. These use Java heavily as well and do not run well with anything made in the last 5 years ... yes dead serious unless there are major upgrades I am not aware of.

My Android SDK wont work on Java 7 yet, and to add insult to injury these same PHBs who refuse to leave XP also have older corporate software like Kronos and Oracle that require IE 6 and java 1.4 from 2004 and refuse to upgrade. Ironically Java is preventing Windows 7 migration as well because old java is not Windows 7 compatible and their intranet apps that use Java are optimized for IE 6 & 7 so you are talking millions to upgrade.

Sap, Kronos, every financial institution, all use old java and wont upgrade until more corporate cusotmers upgrade and corporate customers wont upgrade until banks require it etc. It is a catch 22 and why slashdotters scratch their head. ... ok end rant.

As you can tell I do not like Java anymore as its costs are terrible.

Re:There are tons (1)

CubicleZombie (2590497) | about 2 years ago | (#40485919)

I run into that exact same problem with browsers ALL THE TIME. In fact, I have IE6 on my PC right now because the corporate intranet site doesn't work with anything newer. Now the customer wants the product tested on IE8, forcing me to upgrade, which is going to totally hose the JavaScript application I'm working on AND I probably won't even get paid anymore because I can't even fill in my timecard!

So some incompatibility with an old obscure Java 1.4 app is NOTHING compared to the debacle of web browsers and thin clients.

Even if it is a problem, it's trivial to deploy an older VM with your software and specify it explicitly because Java doesn't even need to be "installed" to function. Just dump it into your app's default directory and run it. Try that with IE or Firefox! Or even worse, .NET!

Re:Yay. (1)

Anonymous Coward | about 2 years ago | (#40485189)

Our time management web app, inventory web app and a particular in-house web app each require a different version of Java to work fully. Now they will all 'work' with the newest version but with varying quirks that sometimes require going into the Java control panel and unchecking newer versions of Java.

Of course if Java closes some security hole with an update it's very likely that some poorly written Java app that depended on that hole will break. That's not necessarily Java's fault but people will blame Java.

Re:Yay. (1, Insightful)

Anonymous Coward | about 2 years ago | (#40484289)

Are you fucking kidding? Java is the most backwards compatible framework. To a fault it is backwards compatible unless you are using some shitty third party libraries that expose non-public APIs?

Re:Yay. (0)

alen (225700) | about 2 years ago | (#40484969)

well apple is a private API nazi. your app won't get into the app store if it uses private API's. and yet apple is evil.

Talk about clueless. (2)

VortexCortex (1117377) | about 2 years ago | (#40484303)

The Java TCK ensures deprecated stuff sticks around, so you can run older stuff on newer Java Virtual Machines. One of the reasons Java is so bloated is because they want to ensure backwards compatibility...

Re:Yay. (1)

Bigby (659157) | about 2 years ago | (#40484339)

What? I can still run 1.3 compile Java source on 1.7. The backward compatibility of Java is pretty darn good.

Re:Yay. (1)

h4rr4r (612664) | about 2 years ago | (#40484373)

Believe it or not there are enterprise apps that check the version and flat out refuse to run if it is not what they expect.

Re:Yay. (4, Informative)

Anonymous Coward | about 2 years ago | (#40484979)

Everything eclipse based got hit with that when Oracle rightly changed the vendor property of the Sun jvm to oracle, afaik checking that did not even make sense since both version and name of the jvm have their own properties . Sadly no programming language can protect you against stupid programmers, any attempt will be dwarfed by the world producing better idiots.

Re:Boo. (1)

AxeMurder (1795476) | about 2 years ago | (#40484469)

I had some software that wasn't compatible with the newest version of Java. So I kept running an older version until a couple of weeks ago my Diablo3 account got cleared out and an old yahoo account started spewing spam. After using a clean machine on a different network to change passwords etc, I tracked down the problem to an exploit in the old version of Java I was running. I have since fixed it, but the now the older program I was running that needed Java doesn't work. Also before the fix Firefox seemed to think I had about 7 different versions of Java installed that it could possibly use. (although 6 of them were set to disabled). Additionally Java has one of the more obnoxious auto-updaters for windows around, but that's a complaint for a different post.

Re:Yay. (0)

Billly Gates (198444) | about 2 years ago | (#40484895)


The whole damn point of java was to avoid this problem in the first place. The most portable language ever made uses runtimes that check versions and refuse to run or developers abuse RMI to integrate with Windows for those crappy enterprise apps which probably also still require IE 6.

Java was fucking awesome when it was new and mismanagement pissed into the whole thing and ruined it it looks like. There should not be issues where Java 1.4.1 wont work 1.4.2 will ... oh but not 1.4.3.

Add to the security holes in ancient java versions and you have a nightmare. Time to get rid of it as a failure

Re:Yay. (2)

JonySuede (1908576) | about 2 years ago | (#40485331)

How place yourself at the jvm level, how do you fix:

Re:Yay. (3, Insightful)

Bigby (659157) | about 2 years ago | (#40485351)

You touched on the core issue. Many of these apps, especially banking apps, used security holes to accomplish certain things. So when Java fixes the security issue, the app stops functioning.

I have never seen an issue around an API change. Only security fixes.

Re:Yay. (2)

bigstrat2003 (1058574) | about 2 years ago | (#40484087)

That would be fine, except that newer versions of Java do not necessarily maintain compatibility with the old. I have seen newer Java versions break so many apps it's not even funny. Granted, they're probably poorly-written apps to depend on version so specifically. But it's still the responsibility of Sun (Oracle) to maintain backwards compatibility.

Re:Yay. (0)

Anonymous Coward | about 2 years ago | (#40485201)

So it's Sun/Oracle's Fault that the code checks that you haven't updated your JVM? Yes because they should just keep the version numbers in the code the same regardless of what the actual version is?

Re:Yay. (2)

h4rr4r (612664) | about 2 years ago | (#40484221)

On Linux it is not that simple. I have plenty of examples or Java apps that only work on one or the other jvm. On every OS lots of java apps only work with certain versions of java.

Expensive enterprise apps are the most likely to be jvm specific and you can forget about the vendor giving a damn.

Re:Yay. (1)

axlr8or (889713) | about 2 years ago | (#40484337)

Yes, as the two former posters replied. I operate Debian. Quite often I don't get compatibility. The first disappointment was actually the practicing policy of the Debian distribution. You want Sun? Fine, disable Open or gcj. And it didn't work. In all those iterations there was and is always trouble. I've recently come across a fellow that really knows quite a bit about all the troubles with Java, how Linux handles paths, etc. But when I used to run Windows it was trouble also. I even have a tick right now, that if I start any application that uses Java, a good portion of the time it will slow my standard inputs down. I can't even type on the keyboard. Yeah, not a big java fan.

Re:Yay. (0)

Anonymous Coward | about 2 years ago | (#40485423)

open source jre sucking != java sucking

Yuck! (4, Insightful)

Dog-Cow (21281) | about 2 years ago | (#40483965)

The summary makes it sound like fat clients are a bad thing. The web is not an application platform! HTML5 efforts to the contrary, it's just not designed for it. A well-written fat client will behave well even when the network is down or slow. Most web apps become useless, if not outright unusable.

Re:Yuck! (1)

RatBastard (949) | about 2 years ago | (#40484135)

Yep. we've moved some of our apps to web-based clients to save a few thousand dollars in development and we end up spending millions in network upgrades to support clients in rural areas.

Re:Yuck! (1)

h4rr4r (612664) | about 2 years ago | (#40484443)

A few thousand?

Any idea what it would cost to write your app for OSX, Windows, Linux, android, IOS and blackberry?

We have found the cost savings were very worth it, rural clients can use 3G connectivity.

Obviously this depends highly on what your business needs to do.

Re:Yuck! (4, Insightful)

Yvanhoe (564877) | about 2 years ago | (#40484625)

It is interesting that web development's big edge today is not in accessing remote content but in providing a compatibility layers on for platforms that do their best to avoid being compatible.

Once again, millions of man hours will be wasted solving a completely man-made problem...

Re:Yuck! (1)

h4rr4r (612664) | about 2 years ago | (#40484903)

Absolutely. The sad part is so far this is the best solution we have.

Re:Yuck! (1)

Anonymous Coward | about 2 years ago | (#40484583)

Indeed. Browsers weren't designed to be application platforms, and web development is a tedious nightmare of inconsistent, ever-changing cobbled-together layers which only exist to cover up the awfulness of javascript, html and annoying browser idiosyncrasies. It takes far longer to develop a stable web application than it would to do it in say Java/Swing, and it's much harder to maintain or modify because there are so many framework libraries to deal with (which seem to be deprecated almost as soon as you've figured them out). Web development is really the worst way of creating software anyone's dreamed up so far.

Re:Yuck! (0)

Anonymous Coward | about 2 years ago | (#40485419)

On the other hand, the best web applications are far superior to the "fat client" alternatives. People would much rather use Google Apps than the best possible Java-based office suite. Web Apps rule if you've got the talent.

Re:Yuck! (3, Interesting)

2starr (202647) | about 2 years ago | (#40484671)

Yes, exactly. That article is just a load of utter BS. For "exhibit A" I give you an article from half an hour earlier [] . Think clients are extremely hot right now in mobile apps! Use the right tool for the job. Sometimes that's a thin client, sometimes it's thick. Stop trying to tell me that one or the other is dead. Neither will be anytime soon.

Re:Yuck! (1)

Billly Gates (198444) | about 2 years ago | (#40485091)

Then how do you get this fat client to install on 20,000 desktops and have it work on the graphics teams macs and the CEO's ipad and iPhone?

HTML 5 is just the graphics and presentation part, but webSQL is interesting to say the least. Java, or any other frameworks belong on the cloud or server and with HTML 5 you can output it to any client and not have to maintain it or debug it. Web apps do work if you look at and Google? Now if we can leave IE 8 and earlier behind we can all switch to AJAX, HTML 5, and CSS 3. That is going to be challenging with all the XP loyalists out there and IT departments scarred from IE compatibility with version 6 wanting to upgrade anytime soon.

Re:Yuck! (0)

Anonymous Coward | about 2 years ago | (#40485393)

Then how do you get this fat client to install on 20,000 desktops

It's very easy with active directory & group policy to deploy applications.

and have it work on the graphics teams macs

There are management agents which can deploy software on macs. Generally, they cost a lot and suck.

and the CEO's ipad and iPhone?

Blackberries make it very easy to deploy software. There are management tools to do similar things for ipad & iphone, but I haven't found any that I like.

Mobile phones, not mobile in general (1)

perpenso (1613749) | about 2 years ago | (#40483989)

... if it weren't for mobile pushing us back to client-side development.

Mobile phones, not mobile in general. Regular web pages work pretty well on tablets and personally I often find myself preferring a site's web page to the site's mobile app when using a tablet.

Re:Mobile phones, not mobile in general (1)

GameboyRMH (1153867) | about 2 years ago | (#40484071)

You don't really buy those arguments about screen size do you? The push towards native apps has little to do with usability, web apps are easy to reformat for smaller screens...follow the money.

Not so fast... (0)

dmomo (256005) | about 2 years ago | (#40484011)

Some of my fattest clients have the deepest pockets. They're the ones who keep food on BOTH of our tables.

Preaching to the choir (0)

Anonymous Coward | about 2 years ago | (#40484051)

they take forever to expire, this one guy's been in my lobby for a week

Yuck!! (3, Informative)

Anonymous Coward | about 2 years ago | (#40484057)

Silverlight is dead like VB6 is dead...

The technology will live on for a long time - it is still the best option for developing RIA LOB applciations.

I'm a native guy - HTML/Javascript is just not a solid method for developing applications.

Re:Yuck!! (2)

White Flame (1074973) | about 2 years ago | (#40485683)

I'm a codegen guy. HTML/Javascript is just another transparent code target as far as I'm concerned.

Did anyone else misread the headline? (1, Funny)

mark-t (151149) | about 2 years ago | (#40484061)

I had initially misread it as "The long death of fat cats".

My brain was all like, "What the hell?" Then when I opened the page to read comments I read the headline correctly.


Nice Title (2)

jareth780 (176411) | about 2 years ago | (#40484083)

"Or we would be, if it weren't for mobile pushing us back to client-side development.'"
Slashdot submission right before this one:
"Facebook iOS App Ditching HTML5 For ObjectiveC"

So it's neither long nor a death for fat clients after all?

Very good, Louis. Short, but pointless.

fragmentation (4, Informative)

recharged95 (782975) | about 2 years ago | (#40484085)

Death of the fat-client makes sense for the multimedia, e-commerce world.

But for real-time, mission critical? I'll stick with fat-clients with a mobile component for now.

Oh god, here we go again with the thin clients (5, Insightful)

crazyjj (2598719) | about 2 years ago | (#40484101)

Thin client computing is like cold fusion. Every so often it's going to be the next big thing...then everyone forgets about it for a while....then it's going to be the next big thing....then everyone forgets about it for a while...rinse....wash...repeat.

Re:Oh god, here we go again with the thin clients (1)

dokebi (624663) | about 2 years ago | (#40485749)

Thin client computing is like cold fusion. Every so often it's going to be the next big thing...then everyone forgets about it for a while....then it's going to be the next big thing....then everyone forgets about it for a while...rinse....wash...repeat.

What's different about thin client computing this time around is that internet is ubiquitous and wireless. Gmail is 8 years old, and Google maps is 7 years old. Siri is a thin client.

Thin client computing is just computing now. The big switch already happened. It just takes 10 years for all the legacy apps to get replaced, like it took 10 years for DOS to be discontinued after Win 3.0 came out. We are basically half way through this process, which means about 1/5 to 1/3 of the apps have switched. The rest will inevitably follow.

There will always be thin/thick clients (3, Insightful)

Bigby (659157) | about 2 years ago | (#40484111)

...just like there will always be death and taxes.

In fact, both are subjective. You are only arguing about how thin or thick the client will be. It is not a black/white is grayscale.

It's too bad (1)

BenSchuarmer (922752) | about 2 years ago | (#40484301)

that there isn't an app for that.

what bullshit! (1)

sribe (304414) | about 2 years ago | (#40484359)

The summary is basically trying to claim that only a handful of cross-platform toolkits count. In other words, according to the summary, applications written in .NET that access a database are not fat clients, nor are ones written in Cocoa, MFC, C++ Builder, Delphi, Qt, WxWindows, Zoolib, etc. And that is a complete load of crap.

What makes a fat client or thin for that matter (0)

Anonymous Coward | about 2 years ago | (#40484397)

It seems that there is some confusion around the "why" when determining the use of a fat or thin client or thick client or round client or equilateral client...

Let's say that I want to create a tool that I myself am going to leverage. Why would I go to the effort of web-enabling it if I'm the only one using it. Now if I have 10 people that can use it I probably would still develop a fat client. If I have 1000 then maybe I would think about a thin client. If I need to share a common data repository then maybe thin or still fat. If I need to make the tool available across many different platforms then maybe thin. If I need to crunch a massive amount of information on the backend with minimal front-end artifacts then maybe a thin client. It just depends. It's like saying an SUV is the end-all be-all for utility vehicles. I've never seen an SUV hold 100 ton of rock before.

Fat clients were always bad. (0)

Anonymous Coward | about 2 years ago | (#40484439)

Fat clients were always all about vendor lockin. Just a crass commercial attempt to sidetrack the web revolution into a cash cow. No tears from anyone but a bunch of amoral PHB/MBA assholes. (of course, the waning of fat clients also includes appstore-type apps - also no great loss.)

I've been hearing this for years (2, Insightful)

Anonymous Coward | about 2 years ago | (#40484463)

People have been saying that fat clients are dying for years, however I'm still making a good living writing them. I was getting a little worried until Apple brought them back as a big way by re-branding them "mobile apps" and making them s3xy again. The OP says as much: "Or we would be, if it weren't for mobile pushing us back to client-side development."

Thin clients have their place, but there will always be fat clients, simply because they work better in more environments.

Oh yeah? Then why multi-core smartphones? (1)

Animats (122034) | about 2 years ago | (#40484527)

If fat clients are dead, why do smartphones need so much compute power? Smartphones now have 4 cores on the main CPU, a GPU, and several auxiliary microcontrollers.

fat clients work well in some worlds (1)

Teunis (678244) | about 2 years ago | (#40484573)

games: world of warcraft and all the myriad clients based on the Unity3D engine do count as "fat clients"

trick is : a fat client needs to provide something a thin client can't. On mobile this would mean handling disconnects and offline well (which thin clients aren't particularly good at) - or services not yet available (like fast 3D rendering).

Java is still somewhat competitive because it can deliver capabilities not present in thin.
Flash is not competitive anymore - it offers little not present in html5 and is closed from some markets.

This is one of those things that run in circles. One interesting historical example: X11 terminals being replaced with X11 desktops, and then the X11 desktops working thin clients once more.

Fat/Fast (2)

EvilElk (2664953) | about 2 years ago | (#40484611)

This is so full of shit. If you want a rich/complex experience with fast response, fat client is always going to be the way to go (well, until bandwidth approaches infinity and central server hardware cost approaches zero).

Fat client ? (0)

Anonymous Coward | about 2 years ago | (#40484631)

nah ... just big boned ...

captcha : homicide

Another great thing about the US (3, Funny)

GodfatherofSoul (174979) | about 2 years ago | (#40484857)

We'll NEVER run out of fat clients

Mobile IS fat client (0)

Anonymous Coward | about 2 years ago | (#40484859)

Mobile apps on the go... no matter what technology (native, phone gap or whatever) are really fat client.

AND Oracle is working on implementing JavaFx for iOS. It could be a cool platform for all java devs out there.

Circles have no end... (4, Insightful)

AtlantaSteve (965777) | about 2 years ago | (#40484953)

I've been in software development for about 20 years, and it occurs to me that I've seen the "fat-to-thin-to-fat" cycle of hype run its course at least twice now. Predicting "The End of Fat Clients" (or thin clients for that matter) is like looking at a clock, seeing that it reads 6:00, and then declaring the death of noon.

Re:Circles have no end... (0)

Anonymous Coward | about 2 years ago | (#40485433)

The problem is browsers are really inefficient at using clock cycles, memory and network bandwidth.

If you try to do something powerful with them, the scaling breaks. Hence the reason why Google maps and Google earth are different apps and one isn't based on a browser.

Until we can stream full video to an end device over the internet without any issues then there's no real way to locate the resources on the server. Considering an uncompressed 1920x1080 30fps stream easily eats 30mbit of bandwidth, that won't happen anytime soon. Cisco and Juniper has been badly straddled by not investing in their fabs and are still on 120nm processes while small competitors are moving over to 30nm processes. The problem has always been reliable clock cycles for WAN links; DSL is an example of that. Wait for it, someone will figure out a way to get 100mbit out of DS0 wire in the next 10-15 years, and then we'll see some real changes.

Re:Circles have no end... (1)

Bucc5062 (856482) | about 2 years ago | (#40486025)

Been in it a little longer, have seen and said the same thing. The more things change the more they get rehashed into the same thing with better marketing.

Here we go again... (3, Insightful)

dkf (304284) | about 2 years ago | (#40484967)

The wheel turns, but we stay in largely the same place. Sure, the Java fat client might be on the decline, but the Javascript fat client is bloating up rapidly. That'd be OK as it is far less fussy than Java and quite a lot higher level, but JS is a dratted awkward language to write well; it's got too many weird things in scoping that can trip you up horribly if you don't know the magic workaround idioms. (It's also coupled to the DOM and HTML in most peoples' minds, and that's certainly not nice.)

In any case, fat clients aren't going anywhere. They're just changing the details of their implementation. Similarly, cloud computing is very much the same as a much older concept, bureau computing, but cheaper and with faster networking so people don't notice as much. The IT industry has such a horribly short memory...

Re:Here we go again... (1)

girlintraining (1395911) | about 2 years ago | (#40485931)

The IT industry has such a horribly short memory...

It's because there's still a 640k limit on the 15 hertz 'Human Brain' PC...

Business Apps need a Fat Client; Go Silverlight! (1)

danparker276 (1604251) | about 2 years ago | (#40484971)

Silverlight is supported until 2021 or something, and at least I feel it's feature complete to do everything I want it to. Even if it goes away it's not that hard to port everything to WPF or Metro. Metro is a fail for business apps because it's a closed system and you have to submit apps to the marketplace. It really doesn't matter WPF or Silverlight to me, but Silverlight is easier to install and can be used on mac and windows. Yeah everyone can write a fun website, but it's business applications that pay the bills for most of us. HTML can't and never will be able to do things like print a document correctly.

a never ending story (1)

AtomicAdam (959649) | about 2 years ago | (#40485025)

I humbly submit that this is a cycle that we will have to deal with for a long time.

Fads, fads and more fads (0)

Anonymous Coward | about 2 years ago | (#40485035)

First we had applications. Then applications were uncool and we were going to have web pages for everything. Then 'apps' became the New Cool and instead of using a web page we now install a program which does the things the web page used to do.

Every few years a new generation of developers decides to throw out what used to work and Something New, without realising that the Something New is just a shinier version of what the last generation but one were doing.

Sorry but.. (1)

JustNiz (692889) | about 2 years ago | (#40485055)

Sorry but bandwidth will never be a good substitute for local processing power. Thats all there is to it.

A totally uninformed post... (1)

Anonymous Coward | about 2 years ago | (#40485107)

Microsoft is getting rid of Silverlight... and replacing it with 1. Metro 2. WinRT + XAML, which it is adding to WPF + XAML.
Apple was going to release the original iphone with no Native API, but HTML based apps. Today there are OSX apps, and two flavors of iOS apps.

Google did all web stuff, and now they do web stuff and native android apps.

See a pattern here? The idea that web script kiddies will inherit the earth when HTML5 is a starvation medium when compared with most rich client apps is ridiculous. The idea that we would squander computing power on some wasteful server side (aka, big iron) model even as ever more power gets shoved into the farthest and tiniest of devices imaginable would be a failure of engineering imagination of the first order. The only thing going extinct are web browser plugins: Flash and Silverlight, because HTML5 can take up the slack (almost). The rest of the world will go native because native is how you get the most out of tiny devices.

Two Words Maintainability and Testability (0)

Anonymous Coward | about 2 years ago | (#40485111)

HTML/Javascript are a maintenance and testing nightmare.

Web Delivery Dying, Fat clients healthy as ever! (4, Interesting)

evilviper (135110) | about 2 years ago | (#40485315)

We are on the verge of a purely HTML/JavaScript client world.

No, no we aren't. We are on the verge of WEB SITES being restricted to using WEB TECHNOLOGIES.

It was an idiotic idea back in the '90s to believe that people WANTED to open a browser, and visit a web page, to launch their client-side apps. A local app on a fat client is still the be-all, end-all of computing.

People may tolerate web apps, but they usually don't WANT them... They're just given no other choice by the developer, usually for reasons of ad placement. Companies like Pandora have their web app, but then have a desktop Adobe AIR version of their web app, but ONLY for PAYING customers.

Hulu was smart enough to release Hulu Desktop to let people get away from their clumsy web interface, but they sure haven't advertised it's existence, and I'd have to call it "quite buggy" even being generous.

Fat clients remain dominant. Smartphones aren't anything special... They just happen to be a huge new money-making opportunity, so developers aren't going to cut-corners (depending on web apps) to capture that market.

Ever heard of the app store? (0)

Anonymous Coward | about 2 years ago | (#40485327)

They're not selling thin clients...Some would say the thin client is the way of the past and fat clients (ya we call them apps now when we go to starbucks and buy lattes) are the wave of the future...

The myth of the thin client (1)

Adrian Lopez (2615) | about 2 years ago | (#40485329)

With ... Microsoft's move from Silverlight to Metro ... We are on the verge of a purely HTML/JavaScript client world.

Windows Metro is HTML5 based but depends on a bunch of Windows-specific code, so calling it pure HTML/JavaScript is quite misleading.

It's not really a thin client if most of the heavy processing takes place client-side. All it is is a different way of representing and delivering the same code.

Adobe (2)

jbolden (176878) | about 2 years ago | (#40485361)

I find the whole summary rather interesting. It starts by mentioning Adobe's divestment of Flex, which really is a thin client architecture. You'll notice that Adobe's apps are still mostly fat client. You download and install CS6 the only "cloud" thing is you pay a monthly service fee rather than have to buy all at once. The article also fails to mention .Net and Objective-C/XCode.

In terms of desktop widget sets
Windows = .Net
Apple = Cocoa
Firefox... = XUL
Gnome.. = GTK+
KDE = QT []

This cycle has been going on since the 1960s. In systems that are cost efficient special case stuff gets pushed out for speed. This leads to systems that are difficult to manage so stuff that was pushed out gets pushed back into general purpose for cost. We are in a world where mobile is pushing stuff out (i.e. platform specific) and desktop is pushing stuff in (web applications). But we are far from a world where either paradigm is uniform.

JavaFX + Scala or Groovy = UI development goodness (2)

MCRocker (461060) | about 2 years ago | (#40485775)

I was a little disappointed that, for a topic that mentions JavaFX, there hasn't been any significant discussion about JavaFX at all so far.

I'm admittedly not a UI developer, but, I've been playing with ScalaFX [] and looking at GroovyFX [] and seeing a lot to like (See JavaFX 2.0 and Scala like Milk and Cookies [] ). Combining this stuff with some of the ideas from Morphic [] and we could get some really compelling UI's that would be hard to do in a browser even with HTML5.

Better medicine (1)

chemicaldave (1776600) | about 2 years ago | (#40485789)

With the advent of new medical technologies, our nation's obese are being kept alive longer than ever before!
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account