Slashdot Mirror
The Long Death of Fat Clients
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.'"
Isn't this whole HTML 5 business basically Browsers becoming fat clients, by your definition?
...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!
"When information is power, privacy is freedom" - Jah-Wren Ryel
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.
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.
... 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.
Some of my fattest clients have the deepest pockets. They're the ones who keep food on BOTH of our tables.
they take forever to expire, this one guy's been in my lobby for a week
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.
File under 'M' for 'Manic ranting'
"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.
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.
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 political party do you join when you don't like Bible-thumpers *or* hippies?
...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 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...
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.
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 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.)
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.
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.
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 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.
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).
nah ... just big boned ...
captcha : homicide
We'll NEVER run out of fat clients
I swear to God...I swear to God! That is NOT how you treat your human!
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.
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.
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...
"Little does he know, but there is no 'I' in 'Idiot'!"
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.
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.
http://saveie6.com/
I humbly submit that this is a cycle that we will have to deal with for a long time.
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 bandwidth will never be a good substitute for local processing power. Thats all there is to it.
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.
HTML/Javascript are a maintenance and testing nightmare.
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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...
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.
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
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 .Net
Windows =
Apple = Cocoa
Firefox... = XUL
Gnome.. = GTK+
KDE = QT
http://en.wikipedia.org/wiki/List_of_widget_toolkits
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 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.
Signatures are a waste of bandwi (buffering...)
With the advent of new medical technologies, our nation's obese are being kept alive longer than ever before!
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!
.NET!
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,
:wq
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".
Heh, I posted about our payroll system above that requires older java. It's Kronos.
This takes me back 15 years to the last time we had this debate....
What I find so comical is the attitude that HTML5 / Javascript is somehow synonymous with freedom...
I don't know what kind, but FREEDOM. Freedom from Flash, freedom from Java, freedom from Microsoft, freedom from ... wait for it ... Apple.
For Chrissakes, go plant a friggin' garden.
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.
Cantankerous old coot since 1957.
...die rather suddenly. Usually heart attack. Strange.
Great warrior...hrmph! Wars not make one great.
The author apparently doesn't know that Metro *IS* a fat client.
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.
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.
Please do not read this sig. Thank you.
Modern work sites and newer intranet software run on any W3C complaint browser and platform. The probelm isn't all browsers, but java/IE 6.
I have a VM and it is time to use one and talk to your bosses about it? No developer can survive without one anymore because everyone runs different software as we are in a period of transition. You can't function because corporate America is in a phase of change due to XP cancelling support and are busy migrating to Windows 7. Even if your own beancounters say NO, you need to document this and have your boss write a recommendation and include the costs for VMWare or VirtualPC so they can counter the beancounters so they can eventually say YES. Otherwise they are under the impression you can write a javascript program and it will always work in all platforms forever. Why change?
It is obvious IE 6 is NOT fine. Neither is the older apps and support is ending anyway and it is time to get with the program.
The whole idea of a thin client is to avoid browser lockin. Fat clients use Java crap or some software activeX control that is depenent on another server program which was written for a browser because it is old. New thin clients using HTML 4/5 can work with IE 9, FF, Chrome, and all portable devices. Just a minor CSS for a particular browser or mobile device if any issues are found. NOTHING like the hell you are going through now.
Things like Java is what is keeping platforms that should have died 5 years still running. I agree and got modded down before that Java does not belong on the desktop anymore due to issues like you described. Technology changes and Java is one of those things that have kept IE 6 and XP still around when it should have died in 2009.
http://saveie6.com/
Kronos should have an updated version that works with things not made 8 years ago! I guess they do not want to write 2 versions but something has to give and they should not charge corporate customers more money whichi s probably what they are doing because they are greedy and are aware of the situation.
Helpdesk calls for malware are a huge support costs and most IT departments do not have the time to make extensive whitelists of java enabled internet sites for certain workers so they have it enabled corporate wide and these same users get nailed with an ad.
http://saveie6.com/
Anyone else find it amusing that this is just above an article talking about Facebook ditching HTML5 to go to ObjectiveC instead?
yeah.. programming for the FUCKING webbrowsers is just soo simple, consistent and enjoyable, i envy my developer colleagues every day (sysadmin, myself) MUARRRHARHARH
"thin clients.." my ass, who the hell is stupid enough to believe that it is possible to have the same functionality in the browsers as in a fat client without the same amount of complexity ??
Everybody it seems!
ba dum psh!
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.
New thin clients using HTML 4/5 can work with IE 9, FF, Chrome, and all portable devices
Wait till HTML6 comes out, or IE 11, or Chrome 32, or FF 708...
Another "WebApps will take over! Client development is dead!!!!11!" story. Anyone remember this same story 10 years ago? *snore* Nothing to see here. Move along. Hey 10 years ago... wasn't that back when they first started speccing out HTML5? ;)
I've been using JavaFX with Groovy, Scala, and Jython (maybe Clojure soon), however, didn't elect to use GroovyFX or ScalaFX. It's pretty simple to just use Scala and JavaFX or Groovy and JavaFX together without some additional binding technologies which may or may not keep pace with the development of the GUI platform itself.
I still believe that I will have the option of deploying my application to a Web environment if I want, but honestly, I just don't see much advantage to it in the case of my particular application. Presently, web integration involves the client installing JavaFX plugins and other non-ubiquitous components. Later, I anticipate that this process will be streamlined as to be as painless as installing Flash. If not, I don't really care. My target domain is the thick client.
With the WebView component within JavaFX, I can extend my reach to HTML5 technologies to fill any gaps. Since my application deals with visualization, some of the finest visualization frameworks are within the HTML5 space. D3, for instance is a very well thought out framework I use extensively in the Dex Data Exploration application.
Also, the JavaFX community reminds me of the helpful nature of the newsgroups of yesteryear. Respectful, and above all, helpful. I'm a big fan of the current direction of JavaFX, despite what I believe were missteps in it's infancy.
Lynx anyone? Also, you don't have to leave the command line to use it.
Not a problem. Newer browsers read older w3c complaint code fine. IE 6 doesn't use older standards. It uses older standards in a very different way requiring a near rewrite. Java is just as bad as programmers try to use security holes to use COM objects. When the fixes come in they break the app.
Poorly written IE 6 and Java apps are not compliant with each, let alone standards. That is why businesses can't leave dying XP behind. Java needs to go as that and not proprietary web based code is the reason for incompaibility.
http://saveie6.com/
New JVM's run older java compliant code fine as well. The problems come when people use non-public API or use it in a way that it is not intended.
I'll guarantee you that poorly written HTML5 code will not play well between different browsers and browser versions.
That's OK, you can just install a custom VM for each web/Java app you need to work with. Aren't you glad to have the simplicity and convenience of run anywhere web apps? Huh? Time for my meds already?
Sometimes there are dependencies on old 3rd party libraries that have been superseded.
Other times, it's self inflicted. Custom Swing look and feels are a no-no - Java 6 changed a lot of stuff.
And you hear stories where enterprise servers run on Java 1.3 on a pre-historic version of Websphere because there's not the inclination to migrate old code nor upgrade licensing.
mcgrew is right. .. solid. .. spin = good!
slashdot by itself is killing the user.
there's nothing in the 90% unknown dark matter/energy universe
that merits "thin" or semi "fat" clients.
this has been m00t from the day that schools teach what teachers see on their
thin client connected devices and teach to their students.
fortunatly, the solid-core internet programs are just that
so the spin stays and the the spin can be; and rightfully? so.
but babies should know, that the chip their holding is the same chip that
the dark matter/energy is holding.
result: nukes = bad / solar = good
Now the customer wants the product tested on IE8, forcing me to upgrade
Hello, this might save your ass like it saved mine. I'm not affiliated with them in any way. It allows you to run the rendering engines for multiple Internet Explorer browsers without having them installed. The stand alone IEs were a pain in the ass to get working on Windows 7 64bit, while the performance isn't great it sure beats having to load a Windows VM to test your site/application with.
Man blir trött av att gå och göra ingenting.
As a UI developer, I find ScalaFX and GroovyFX to be infants, concerned too much about layout, and not about the things that really make UI development challenging. In my latest Scala and JavaFX toy project, I felt I was far better off using the Java interface and using Scala for the things it really does well.
Also, JavaFX is still in its infancy, so it's still a very hard sell for production applications. The architecture is very clear, but extremely verbose. The components that are there are beautiful, but severely lacking in features: Want any interaction whatsoever with the chart component, for instance? You have to build it all from scratch. The grid component has less features than even web grids. Investing in it now is like investing in Swing in the early years: You end up having to write all kinds of code for generic stuff you shouldn't, and then spend money removing your customizations if the standard components ever get better.
If Oracle actually cared about JavaFX, it has to mature far faster than it's doing now.
"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"
.. the NC attack plan .. We have been closely monitoring, attacking, and winning NC threatened accounts"
We would be except Microsoft killed the NetPC and Microsoft doesn't have the same influence in the mobile space to do the same thing.
"On the NetPC - Pat thinks we are being slow to follow-up and get the spec's out, and he is telling his guys to go ahead and start drafting
AccountKiller
The webview component is, in the end, yet another target browser with its own set of inconsistencies and problems. The guy in the next office has been having all kinds of fun trying to use the webview component in a swing app, using an embedded javafx scene: Javascript components that work fine in, say, firefox, have rendering problems in the web view that make pages utterly unusable.
Here is the picture I posted with the article on my site: http://osintegrators.com/sites/default/files/Jqueryzilla2.png -- I think it adds something no?
Yet everything you've mentioned has nothing to do with Java except the custom look and feel, which I find hard to believe since it isn't mentioned in the Java 6 migration documentation.
Swing had subtle tweaks to things such as focus. Code that worked on a 1.4.2 and 1.5 VM did not on 1.6 - such as trapping mouse events.
This is probably an example of a 3rd party look and feel not doing the correct thing but frustrating nevertheless. I wish managers would just use the system look and feel instead of wanting a custom skin for their application.
+1 For this & link included.
I was huddled under my desk in fear that I'd get rolled into a massive corporate JS goose chase, but then Dart gave me a ray of hope. I just tried it out for the first time yesterday and it held up to its promises: I was productive within 30 minutes of downloading the SDK, and it didn't relieve me of all my most powerful tools for fighting complexity (like proper OO, and by 'proper' I mean non-prototypical).
It's still pretty bleeding edge, and there's some ground left to be covered, such as reflection and JS library integration, but it's a damn sight better than the alternatives I've seen (Ember, Backbone, etc).
Thin client? What, like a dumb terminal on a mainframe? And that's good, is it?
... should make a diet and make some exercise and become thin clients or at least only a bit overweight.
http://www.eclipse.org/eclipse4/
Eclipse is still a good option for at fat client.
I do welcome back real (fat) client software, that are not artificial restricted by the web.
I welcome back development of real software, where developers has the freedom to produce what they want, how they want, and not litten to HTML Script Kiddies.
What is wrong with downloading a program and installing it? Im not saying it can be made easy, say apg-get or webstart... but for god sake, why should I run programs in a browser and be forced to microlag (lag between 100ms-5s) .. when I dont have too? Im all for fat clients.
For people that do not know, micolag is the lag that is so little that you dont start to do something else, but is greater enough for you to get enoyed. If I click something and it triggers something on my screen within 100ms, humans thinks its instant. If its over (about) 5s, then we tend to travel the mind.
Now for real, you diehard web-client developers answer me, you never get microlag on your software running in a browser?
Guess what, not so much in fat clients. There ya go.
I write my fat clients in Java/Groovy and use Swing. I don't see what is wrong with that or that it will die soon. Others might prefer Qt and C++ though.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Most webapps run like molasses on my Atom Netbook. How is that "thin"?
...someone who wasn't around during the mainframe/minicomputer era who has a vested interest in shifting horsepower from the desktop to the server room comes along and makes me chuckle.
We got away from thin clients because 1) the performance is variable and lousy, 2) single point of failure in the network causing the device to become useless, 3) they dont save any money and in fact may be more expensive, 4) the user loses control of what they can and can't do, 5) the user has to wait on someone to develop the back end service before they can use it on their client.
So basically its a solution with a lot of problems in search of a valid application.
When commercial fat clients disappear, people can easily migrate to all the FOSS desktop apps we have, which will be still supported. We'll all be better off.
..everybody uses statically typed languages. Aerospace, Medical instruments - code can kill people. That's why statically typed languages such as Ada are used.
GWT is a quite solid environment and "feels" very much like common Java GUI development. But yeah, Java is quite strongly typed... Removing all the hassle of application deployment (== registry mess, DLL hell) is indeed a rational goal to go after.
..allows for debugging via Eclipse.
..that nobody at Adobe Inc. seems to have a proper Computer Science Education. They are incapable of doing basic things like writing proper, strict parsers. They really think it is a good idea to try to fix "typing errors" with really brain-dead heuristics in things like the PDF or Flash parsers.
What is the result of all that incompetence ? Adobe products are the Premier Malware API. When I have my tinfoil hat donned, I always claim they are in the pay of Beijing.
Get rid of Java ASAP. Next to Flash it is the most dangerous thing in the computer world.
Microsoft copied Java to the point of having the same issues with runtime library versions as the Original, Java. It turns out that Java was not a real threat (you can't make compelling, high-performance, realtime games and applications with it), but Bill Gates made sure this threat was responded to.
In my experience, GWT-based apps will run nicely on various different browsers and various different versions of each. Those geniuses at Google did some pretty hard work to make that happen. Because they need this kind of infrastructure to make Google Mail and Google Docs happen.
No, I don't work for Google, I think they are collecting like crazy and final no, GWT is not hardwired to the Googleplex; it is a very nice, reliable and well-made piece of open source.
A) Well-designed Chinese Spearphishes (ask Lockheed Martin and their F22 team)
B) Busty Russian Viruses
The "Google Computer", of course. It will contain all your data, nicely indexed for those who pay for The Computer.
.. we have LaTeX and OpenOffice. You can run those as libraries or efficient command-line tools on a server to generate a nice-looking PDF, which the user can then print. We can also render these documents into a bitmap to send it to a web app for display.
I know M$ hates everything which is a real alternative to their technologies, but maybe you want to get out of their claws and enlighten yourself to other options. Options which are not monolithic, but an orchestration of many free, reliable and compact tools. You could start with GWT, Perl, pdf2latex, Apache, Linux.