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.'"

Comments

Um...

[Anonymous Coward]

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

Re:Um...

[Johann Lau]

Yeah, but *heavily* crippled ones.

28c3: The coming war on general computation

Re:Um...

[mcgrew]

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

[CubicleZombie]

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

[icebraining]

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

[Anonymous Coward]

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 god, here we go again with the thin clients

[crazyjj]

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.