Forgot your password?
typodupeerror
Programming

The Long Death of Fat Clients 277

Posted by samzenpus
from the slimming-down dept.
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?

    • 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 [youtube.com]

      • Re: (Score:2, Interesting)

        by cpu6502 (1960974)

        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... (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.

          • by matrim99 (123693)

            I believe the goal for this idea was to have a browser that uses very few resources and is very fast, and the user has the option to add only the functionality that they desire. The effect is to allow the user control over how much of their system's resources their browser uses.

            There are many people who would like to use the web who have slow or unreliable internet connections, or have impairments that force them to access information differently than the rest of us. Thus, a text only browser makes sense

            • I believe internet explorer still has the option to turn off image rendering, displaying those ugly square boxes instead. I don't have to worry about video right now because there is no flash installed on the Firefox I use at work.
        • compile your own firefox, without the built-in libraries

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

          You know what, there actually is!

          https://github.com/jwise/28c3-doctorow/blob/master/transcript.md [github.com]

          that doesn't include the Q&A section though, which is just as long (30 minutes talk, 30 minutes Q&A) and interesting, if not to say important :)

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

      by mcgrew (92797) * on Thursday June 28, 2012 @03:42PM (#40484457) Homepage Journal

      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 [slashdot.org] 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... (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?

      • I think you're confused. If you use a service via a thick client, you still end up sending your data to the provider of that service. Otherwise it's not a client, its a standalone application. Put your tinfoil hat back on.
    • 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.
      • by Bucc5062 (856482)

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

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

        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 [github.com].

      • 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.

        • by Cryacin (657549)
          I must be part of the crusty old geek category too my friend. But it's not just the basic OO principles that are out the window. Have you looked into traits? The basic paradigm is, why not let the user implement their interfaces, you know, like an abstract class, but still allow for multiple inheritance. It's like these guys have never heard of the Deadly Diamond of Doom. It was further confirmed to me when I was at a conference with one of these guys, and when I asked the speaker about it, he looked at me
        • Re:Um... (Score:4, Interesting)

          by MrSteveSD (801820) on Thursday June 28, 2012 @10:56PM (#40489591)
          I agree with you totally there. The lack of static typing (or even the option of static typing) seems to be almost universal in scripting languages. The issue goes further than just type safety and avoidable bugs though. Static typing allows you to better express your intent, not just to other programmers (which you can do with comments) but to the program itself. This makes it easy for a development environment to provide useful things like auto-completion. Auto-Complete saves so much time and also helps you broaden your knowledge of the available classes and functions.

          Another issue that sometimes pops up in scripting languages is a lack of constants. I remember bringing this issue up on a python forum and they just told me to use variables instead. When I pointed out that you could easily change the value of the "constant" in code by mistake, I was told something along the lines of "well that would be your own stupid fault."

          There seems to be a general attitude in certain circles that the basic protections you get with static typing and constants etc are somehow pointless or unnecessary. Google seems to recognise their importance though, which is no doubt why they created Dart. I believe they have been using some kind of enhanced Javascript internally for some time. I know there was a push to add things like static typing, classes etc to Javascript but it was resisted.

          It seems bizarre to me that with more and more being done in the browser, we are still stuck with a Javascript, a language that increasingly seems ill-suited to the tasks it is being used for.
      • Re:Um... (Score:4, Interesting)

        by Nethemas the Great (909900) on Thursday June 28, 2012 @06:04PM (#40486595)

        I thought I had lost this argument on ./ Good to know there are a few of us out there still retaining our sanity. HTML5/JavaScript isn't the WORA technology we should be pursuing. It works reasonably well for small, simple clients but trying to apply it to anything requiring a even modest sophistication causes them to get unreasonably expensive to develop, ensure quality, and maintain when compared to Java, C#, C++, etc. and their respective presentation technologies such as WPF and Swing. This really has less to do with "maturity" of the supporting technology and more to do with the fundamental nature of the languages.

        Part of the appeal of HTML5/JavaScript I think are the low barriers to entry, and the "pioneering" or "frontier" romanticism brought out by the anything goes, blank slate, fiddle and tinker until it works approach that's required. In many ways it actually reminds me of the appeal that Minecraft has to so many people. The mature, safe, predictable, and structured/formal languages and technologies just don't carry the same appeal.

      • by Sayjack (181286)

        Despite the demise or imminent demise of Flex. It did have a superb integrated debugging environment that I have yet to find in the Javascript world. Firebug, however, is getting there but I still find it clunky compared to the other integrated IDEs I have worked with in the past.

  • ...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. (Score:2, Interesting)

    by axlr8or (889713)
    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
    • Re:Yay. (Score:4, Informative)

      by GameboyRMH (1153867) <gameboyrmh@gmail.cCOBOLom minus language> on Thursday June 28, 2012 @03:20PM (#40484009) Journal

      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. (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.

        • Re: (Score:2, Insightful)

          by Yetihehe (971185)

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

          • Re:Yay. (Score:4, Informative)

            by benf_2004 (931652) on Thursday June 28, 2012 @03:35PM (#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.

            • by Yetihehe (971185)

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

            • by MobyDisk (75490)

              Lemme guess: Some corporate intranet app? And it only works on Windows and IE6 right?

              I have seen apps compiled under Java 0.9 in 1995 run fine on current versions. But it seems like every corporate slideshow or training app fails miserably unless the configuration is *exactly* right. They go out of their way to make them incompatible or something. They rarely work in Firefox either, even though it uses the same Java runtime!

          • by Dewin (989206)

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

          • by vux984 (928602)

            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.

          • by BoberFett (127537)

            My company's web based payroll system interface is incompatible with newer versions of Java. We're a few minor versions of the payroll software behind because we haven't had the resources to properly test and roll out the patches, so we're stuck with old version of Java for now.

        • 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...
        • by Bigby (659157)

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

          • by h4rr4r (612664)

            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. (Score:4, Informative)

              by Anonymous Coward on Thursday June 28, 2012 @04:10PM (#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:Yay. (Score:4, Informative)

                by Mechanik (104328) on Friday June 29, 2012 @07:17AM (#40491999) Homepage

                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.

                Speaking as someone who is an Eclipse committer, your representation of the situation is not accurate.

                Sun's JVM has different proprietary options than other JVMs. It also has this notion of PermGen space that other VMs don't have, where various classloader stuff and other things can be stored. Run out of space there, and the JVM blows up.

                When you have a Java application like Eclipse that is really big, it's not hard to run out of PermGen, especially because the default size is so paltry. So, the Eclipse launcher needs to be able to modify this size of the PermGen. However, the special command line option to do this is proprietary to the Sun JVM, and if you pass it to someone else's JVM it's common for that JVM to refuse to run because you gave it an option it didn't recognize.

                So, Eclipse has to:

                1. Check which JVM it is launching with.
                2. Is it the Sun JVM?
                3. If it is, pass PermGen options

                How do you propose checking #2 without checking the vendor name of the JVM?

                Maybe you should look into things more before you call a bunch of experienced, professional, open source programmers stupid idiots.

      • 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.
      • by h4rr4r (612664)

        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.

  • 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.

    • by RatBastard (949)

      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.

      • by h4rr4r (612664)

        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! (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...
    • Re:Yuck! (Score:4, Interesting)

      by 2starr (202647) on Thursday June 28, 2012 @03:52PM (#40484671) Homepage
      Yes, exactly. That article is just a load of utter BS. For "exhibit A" I give you an article from half an hour earlier [slashdot.org]. 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.
  • ... 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.

    • 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.

  • Yuck!! (Score:3, Informative)

    by Anonymous Coward on Thursday June 28, 2012 @03:23PM (#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.

  • 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.

    Weird.

  • "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 (Score:5, Informative)

    by recharged95 (782975) on Thursday June 28, 2012 @03:24PM (#40484085) Journal

    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.

  • 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 dokebi (624663)

      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 w

      • by mikeg22 (601691)
        We are halfway through the process? In the office where I sit, approximately 100% of the applications used by our staff are thick client. Nobody uses web apps because they are slow and have poor user experiences compared to thick client native apps.
      • by jrumney (197329)

        What's different about thin client computing this time around is that internet is ubiquitous and wireless.

        Which is going to lead to a lot of frustrating design decisions. 10 years ago, in the heyday of Flash based "thin clients", offline support was something that everyone considered important, because people travel with their laptops and need to get work done on the road. Now, with the internet considered ubiquitous, and frameworks that tried to deal with disconnected use-cases like Google Gears declared

  • 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 scale...it is grayscale.

  • that there isn't an app for that.
  • 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.

  • by Anonymous Coward

    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.

  • 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.

  • 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
  • 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).
  • by GodfatherofSoul (174979) on Thursday June 28, 2012 @04:03PM (#40484857)

    We'll NEVER run out of fat clients

  • 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 Bucc5062 (856482)

      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.

  • by dkf (304284) <donal.k.fellows@manchester.ac.uk> 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...

    • 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...

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

  • by evilviper (135110) on Thursday June 28, 2012 @04:30PM (#40485315) Journal

    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.

  • 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.

    • by mikeg22 (601691)
      Windows Metro is not HTML5 based.

      HTML+Javascript is one of the languages that can talk to the underlying OS. So can C++. So can C#, So can VB.NET.
  • by jbolden (176878) on Thursday June 28, 2012 @04:34PM (#40485361) Homepage

    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
    http://en.wikipedia.org/wiki/List_of_widget_toolkits [wikipedia.org]

    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.

  • 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 [google.com] and looking at GroovyFX [groovyfx.org] and seeing a lot to like (See JavaFX 2.0 and Scala like Milk and Cookies [steveonjava.com]). Combining this stuff with some of the ideas from Morphic [squeak.org] and we could get some really compelling UI's that would be hard to do in a browser even with HTML5.

  • With the advent of new medical technologies, our nation's obese are being kept alive longer than ever before!
  • It's highly amusing that the story directly below this one on the front page at the moment is "Facebook iOS App Ditching HTML5 For ObjectiveC". Things are never as simple as the prognosticators would have you believe.
  • ...die rather suddenly. Usually heart attack. Strange.
  • by mikeg22 (601691)
    The author apparently doesn't know that Metro *IS* a fat client.
  • by slashmydots (2189826) on Thursday June 28, 2012 @05:56PM (#40486491)
    Let me break down my company's decision on this matter because I guess the author doesn't get it. $200+ ea for cheap thin clients. $400 ea for decent modern cheap PCs. Server to just store stuff and host quickbooks = $4000. Server(s) to run 50 thin clients = $20,000+ and a better network bandwidth capability so at least another $10,000. Hmmmmm. I guess it's thick clients.

    If you're thinking "well that's kinda close"...oh yeah, that's right, we use photoshop, publisher, autocad, our 3D design software, our presentation laptops which stream realtime 60fps content, and we burn CDs and use flash drives. Not exactly a thin client candidate here and we're a pretty typical business. As far as I'm concerned, thin clients were old technology and they have almost no place in today's IT infrastructure given the cost of PCs.
    • by epyT-R (613989)

      don't you worry.. when thick clients aren't ubiquitous anymore, they'll rise back up to $5000 for the stripped down model..after all who needs them but 'professionals'? you're a consumer? pff suck it up and buy your iThingy that's all you need.. no learning programming for you unless you want to pay for that 'professional' access to proper hardware.

      if this day comes, I will strip computing from my life.

  • Yes, SaaS and web based apps have their place in life. So do local apps. Neither is going away, ever, despite what some breathless 20-something goofball chooses to post to Slashdot.

  • I make it a rule to treat web sites (I refuse to call them 'apps') as last tier tools. I treat them as occasional conveniences and never part of mission critical work because it could disappear/become more expensive, or otherwise change tomorrow in ways that are detrimental to what I'm doing. tier 1 tools consist of locally stored and executed software that allows indefinite use.

Genius is ten percent inspiration and fifty percent capital gains.

Working...