On one of our NetBeans mailing lists, a new programmer asked a question, how should they build their application that needs to run on ten client machines talking to a MySQL database.
The quick answer was "build a web app."
I just don't understand this. The web app architecture is - c'mon, admit it - ugly for applications that need to have dynamic behavior (e.g. almost every app out there). It was never built for that. HTTP/HTML is a static, document-oriented protocol and markup. HTML came from SGML, which is all about documents and publishing, not dynamic database-driven OLTP applications.
But the browser is ubiquitous. It's the absolute best way to distribute a service out to millions of people. Its the visual channel into the Internet. So we've worked with it. Thousands of developers have grown up building apps using HTML/CSS/JavaScript, session state, multiple tiers and so on.
But it wasn't always that way. When I was fresh out of school, the browser didn't exist, and we built simple client/server applications. The client talked directly to the database using a database-oriented protocol.
There were issues, of course, the primary one being how to manage versioning and upgrades across thousands of machines, each with their own operating system and versions, some of them sporadically connected (e.g. on laptops). One of the key advantages of the web is that you install it in one place, and everybody automatically gets the upgrade. And it runs on everybody's machine. It's so cool.
But today there is Java (write once, run anywhere) and Java Web Start (auto-upgrade to all your client machines). They are mature and battle tested. If your application is only going to run on the local network, there is absolutely no need to create a multi-tiered HTML/CSS/JavaScript monster. You can use traditional client/server, with rich clients written in Java and deployed by Java Web Start talking directly to your database using JPA/Hibernate/JDBC. You can use the visual design tools in NetBeans or Eclipse to visually build your application. No hacking <table><tr><td> garbage.
Having a middle tier also allows you to disintermediate between the clients and the database, which can give you a chance to improve performance and scale through things like caching, pooling, clustering, replication and so on. But none of that is needed when you have a small number of users, so why create complexity when it's not required?
Now, if you're building an application to be accessible over the Internet, or if you need to scale, it's a different story. You need a middle tier, and one that speaks HTTP if you're going over the Internet.
But even then you can use Java and Java Web Start, and your client application can talk to the middle/web tier using a service API. There is no reason why the server should be responsible for composing the UI for your application. It can be a server, not a UIer.
If you have Java antibodies, you can use Flex or Silverlight. Or take a look at Cappucino.
There are reasons why these RIA architectures are popular - they are meant for dynamic applications and dynamic behavior, unlike HTML, which really was never intended to be anything more than a way to display static documents. With these RIA environments, finally we're getting back to building apps with tools and an underlying architecture that match the dynamic application paradigm.
Now, folks like Google want you to keep building browser-based HTML applications, using JavaScript for dynamic behavior to muck with the DOM (note their new browser with superior JavaScript performance). Why? So they can scan your text-oriented application and inject targeted ads. Not possible with RIAs where the application is compiled into byte codes.
But just because it works for Google doesn't mean it works for you or your users, or that it's the best architecture. It's just the architecture we've had to work with for the past fifteen years.
Now, there are times when a web app makes sense, absolutely. The answer, as always, is "it depends." But when someone asks you how to build a database-oriented app please don't just default to "web app". There are other, potentially superior, options out there...
27 comments:
In my present company, we have an application(product would be more appropriate) runs on Java Swing. The Client binary(jars)upgrades happens dynamically to all the client.
I agree with what you've said here, but one thing that you (and everybody else) leave out of the discussion is the ease of development for HTML apps. I'm not talking deployment, I'm talking development. A small set of UI elements with well-understood methods for passing the data around makes for much easier development than your standard client-server app.
A raw DB connection per client is never going to work for lots of reasons, and it seems odd to build an Intranet-only version (that isn't safe to generalize to the Internet), but I can see the appeal of a JavaFX (say) UI fronting a REST based service.
Are there any tools you know of to support that?
Rasputnik: it's funny you say a raw DB connection per client is "never going to work." It used to be how most database applications were written. It was only the seriously high-end apps that had a middle tier intermediary. What has fundamentally changed between now and then where it no longer works?
If you're thinking you may move to the Internet later, then put in an abstraction and you can build a version that talks REST instead of JPA/JDBC.
Tools that support Java FX to REST? I have no idea. I haven't been doing much with Java FX. You would think that REST support in RIA tools would be strong, but last time I played around with this there wasn't much there - most APIs are specific to a given environment and require a lot of hand-coding. This needs to be fixed...
Good post. But most people nowadays are concerned with RDD(Resume Driven Development). It just looks cooler with the jQuerys than the Swings.
Impatient: HTML apps are not easier to develop. Unless you use something like RAP/Echo/etc. But even then ... RCP is easier than RAP.
Amen, brother. When all you have is a hammer, every problem begins to look like a nail.
I'm all for moving away from web apps and back to the traditional naively-compiled application and sockets sending binary data back and forth! Faster, less resources used, more dynamic application, less muss/fuss.
Use the right tool for the right job.
There is also maintenance to consider. A web application gives developers the ability to deploy updates immediately. Updating a desktop app usually depends on the most unreliable part of technology - the users.
Obviously there are ways around this, but many developers are willing to accept the shortcomings of web in exchange for end-to-end control.
"Java (write once, run anywhere)"
Heh. They said the same thing about p-code in Pascal. Only I think p-code actually was WORA.
I doubt there's any large Java system which includes a client UI that didn't involve platform-specific testing and platform-specific code.
A real client application is often a better choice than a web app, but let's not lie to ourselves about how easy it's going to be.
You forgot iPhone. And Android.
"No hacking table tr td garbage"
that's misleading..creating an app frontend is much simplier in html than in Swing.
I couldn't agree more. Although I use different technologies, I find it hard to understand the default position of networked application = web application. I have even seen people write browser-based software for single user applications.
Client applications just seem to flow better and give an improved sense of control to the user.
I like the comment about resume-driven development. That raised a smile.
Nobody mentioned user acceptance/user experience. Web-based applications have UI conventions that almost everyone knows. You know what happens when you click a radio button, check a checkbox or use multiple selection. It's hard to train a user what button does which function. Think of your favorite IDE and how much time it takes to get used to working with it. Now think of having that many applications, each behaving differently, what a mess!
My alarm was the same when you mentioned using Java for the front of a web app - eeewwwww.
I like what you said about building the middle tier with an API right off the bat.
Then, it can go any number of directions.
Nowaday at work Im re-writting Swing App into Web App. I think the problem is Java. With webapp you just need MSIE and you can go crazy. With Swing App you need Java, some companies might not want to have Java installed on all the computer or the computers are so bad that Swing App will not work as fast as it should. With Web App you will never need to solve problems like "I cant start the App" or "It hangs after 5 minutes".
There is another thing being left out of this discussion: Open Source GPL software. One reason web apps at large have been popular is that it has allowed developers to use massive amounts of GPL'ed technology without having to open up their own source code. As soon as you start shipping that code out to end users, you've got to open it all up. True, this doesn't matter inside a company. However when you're building a commercial app it is a huge reason to keep everything on the server.
You make a big assumption that the app will only be used on the LAN. Sooner or later someone has to use it remotely and then you have raw DB connections across the net and it all gets ugly.
Web apps don't have to be complex multi-tiered beasts. Modern frameworks such as Seam make it easy to knock up simple web apps. You decide what layering you want - it's not enforced. Sure there's some complexity such as database connecting pooling hidden behind the scenes, but so what. it works efficiently and doesn't get in the way. The benefit of a good web app framework is very easy deployment and a kit bag that's been optimized (usually) for writing multi-user apps that operate on a light weight DB such as mysql.
anonymous: Have you ever had to build/deploy/maintain a web app? Even if you just target IE they are a pain. You are reiterating points that were claimed years ago but have since been proven invalid.
Michael: I've written plenty of webapps and have not used GPL software. And webapps DO send code to the client. If it is cached, i will be no different than a WebStart app.
Upgradability is not really much of an issue. Everyone auto-updates their thick clients - Skype, Adobe Reader, browser, and just about every other app regularly these days without issues. Oracle Connection Manager (cman) is a solution for handling scalability of connections transparently. Alternatively, using a middle tier and web services solves the firewall tunneling issue and scalability. At the end of the day, is it not more productive to develop dynamic apps as thick clients with fewer technologies?
Awesome - could not agree more, even after developing web apps for several years.
So I think the term "web app" is a bit misleading if not a bit too generic. If you are extending network services in a SOA-esque environment, the "web app" is a quick way to expose services to your network and/or users. The term "web app," for me, doesn't exclusively mean UI elements for user access but instead, network applications running in web containers providing interfaces to services. These interfaces can be REST, SOAP, Servlet POST/GET, or as you mentioned, UI elements via Swing or HTML. The consumers of these "web apps" can be other systems as well as regular users.
So is it the term "Web" or "Application" that suggests HTML to you? Would you suggest that a Web Service has HTML components?
At the end of the day they both can deploy as a war to the container so technically speaking they are both a "web app."
Awesome post! I liked it very much and I do totally agree with the author.
Perhaps the users might have to change their *mentality* and *mindset* from keeping the traditional *BROWSERS* as the One and Only client!:)
Like the way you think...
What if I told you, you can have it all ;)
What about being able to write a normal java application, and it runs stand alone, say a game, accounting app whatever.
Then what if I told you, you can drop it into a server, and the UI side will appear on a remote machine, while the rest runs in the server, say still talking to a dB.
What if I said its faster than a browser, more powerful than flex, and as easy as writing a normal Java app.
Impossible you say... no, we do it every day.
http://www.kewlstuff.co.za/site/index.htm
You will never use anything else again... you dont need it ;)
What you feeling, we did, and damn we happy we did ;)
If you cant use this... its because you cant code ;)
Enjoy
funny, some times ago I heard people calling thick clients are the monster, and now you call thin client is the monster ...
when you happen more proficient in one thing you start to call other thing monsters ... that's signs "maturity" to me.
I've been in charge of creating a web app for (re)insurance broking in the London Market and the general feeling is that our web app is slow. Tables must scroll but the headings must not, they should be sortable, selectable, editable, exportable, you, name, it. It's asking a lot of this HTML static technology and we have to include a lot of script, css, and html to make it functional. Performance is inversely proportional to functionality of course.
It doesn't help also when events can be hard to bend precisely into the javascript event you are actually interested in. There are two models of events with bubbling and capturing, so which HTML element am I actually intending to click on, this can be worked around - but it's a pain in my eyes and something you wouldn't even consider in say a Swing application. I'm always told not to re-invent the wheel, but then when we choose a technology we always decide to change it and bend it away from what we were happy with, make it slower. Then we get complaints about performance again.
My gut feel is that deployment issues are less time to deal with overall than the extra time and effort optimizing performance of web apps in the development stage.
I'm fairly sick of the web-app in reality, it's overworked and bent out of all recognition.
Post a Comment