Follow Slashdot stories on Twitter


Forgot your password?

The Long Death of Fat Clients 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.'"
This discussion has been archived. No new comments can be posted.

The Long Death of Fat Clients

Comments Filter:
  • Um... (Score:5, Insightful)

    by Anonymous Coward on Thursday June 28, 2012 @03:16PM (#40483937)

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

  • Yuck! (Score:5, Insightful)

    by Dog-Cow ( 21281 ) on Thursday June 28, 2012 @03:18PM (#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:Yay. (Score:4, Insightful)

    by Dog-Cow ( 21281 ) on Thursday June 28, 2012 @03:23PM (#40484059)

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

  • by crazyjj ( 2598719 ) * on Thursday June 28, 2012 @03:25PM (#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.

  • by Bigby ( 659157 ) on Thursday June 28, 2012 @03:26PM (#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.

  • by Sancho ( 17056 ) * on Thursday June 28, 2012 @03:27PM (#40484153) Homepage

    ChromeOS is on that track.

    Yeah, but ChromeOS is as dead as BSD. The PS3 browser is used more than the ChromeOS browser. []

  • Re:Um... (Score:5, Insightful)

    by Johann Lau ( 1040920 ) on Thursday June 28, 2012 @03:31PM (#40484227) Homepage Journal

    Yeah, but *heavily* crippled ones.

    28c3: The coming war on general computation []

  • Re:Yay. (Score:2, Insightful)

    by Yetihehe ( 971185 ) on Thursday June 28, 2012 @03:31PM (#40484235)

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

  • Re:Yay. (Score:1, Insightful)

    by Anonymous Coward on Thursday June 28, 2012 @03:34PM (#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:Um... (Score:5, Insightful)

    by Old97 ( 1341297 ) on Thursday June 28, 2012 @03:34PM (#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.
  • by Anonymous Coward on Thursday June 28, 2012 @03:42PM (#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.

  • Re:Yuck! (Score:5, Insightful)

    by Yvanhoe ( 564877 ) on Thursday June 28, 2012 @03:50PM (#40484625) Journal
    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...
  • by AtlantaSteve ( 965777 ) on Thursday June 28, 2012 @04:07PM (#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.

  • by dkf ( 304284 ) <> on Thursday June 28, 2012 @04:09PM (#40484967) Homepage

    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:Um... (Score:5, Insightful)

    by fermat1313 ( 927331 ) on Thursday June 28, 2012 @04:10PM (#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... (Score:1, Insightful)

    by Anonymous Coward on Thursday June 28, 2012 @04:11PM (#40484999)
  • Re:Um... (Score:1, Insightful)

    by Anonymous Coward on Thursday June 28, 2012 @04:14PM (#40485047)
  • Re:Um... (Score:5, Insightful)

    by CubicleZombie ( 2590497 ) on Thursday June 28, 2012 @04:24PM (#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:Yay. (Score:4, Insightful)

    by Bigby ( 659157 ) on Thursday June 28, 2012 @04:33PM (#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:Um... (Score:5, Insightful)

    by icebraining ( 1313345 ) on Thursday June 28, 2012 @05:03PM (#40485791) Homepage

    "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... (Score:5, Insightful)

    by Anonymous Coward on Thursday June 28, 2012 @06:02PM (#40486567)

    I totally agree.

    Last week, I posted a comment bemoaning the lack of type safety in JavaScript. I got ruthlessly blasted by people who claimed that it hasn't been proven that type-safety-checking languages are better and that I was a crusty old fart for hanging onto the old ways and refusing to embrace the new paradigms of purely-dynamic typing.

    I have 25 years of experience that tells me that I've avoided hundreds of nasty bugs throughout my career by having C or C++ catch all my type inconsistencies. Those are hundreds of bugs that I didn't have to spend time tracking down in the debugger. I'm dead serious when I say that if I didn't have a strong type-checking compiler all these years, I probably wouldn't have remained a software engineer for more than a couple of years. I would have long ago lost interest in using a debugger all day long to catch my own stupid-ass typing errors that could have been totally preventable if the language had been better designed. It would have been like digging ditches with a spoon -- fuck that job if they're not going to provide you with the proper tools.

    I'm very concerned that the future of the Web seems to rest on a language that doesn't have even the OPTION to use convenient type-checking -- not even at run time. (It would be possible to add this to JavaScript, but they refuse to do so. Note that later versions of PHP bolted on run-time type-checking as an after-thought, so it's obviously possible to do.)

    I'm sure I'll get mercilessly criticized again for posting the most powerful lesson that I've learned in my past 25 years of software engineering: "having the option to use strong typing is FUNDAMENTALLY BETTER than not having that option". Static type checking is luxurious. But if static type checking isn't possible, then at least allow me to specify the type so that it can be dynamically checked. More generally: if you can lock something down without taking away functionality, then DO IT. Use "const" when you can. Use "private" when you can. Use an enum instead of an int if you can. Open files read-only when you can. Have the compiler check types and issue warnings if you can. Etc., etc., etc. It's amazing to realize that the single most important principle in all my years of experience can really be summarized in just a single paragraph.

    And it's so sad to see the web's language of the future (JavaScript) deliberately ignore my most important principle.

"Oh my! An `inflammatory attitude' in alt.flame? Never heard of such a thing..." -- Allen Gwinn, allen@sulaco.Sigma.COM