The question is quite simple:
Can we use JavaFX as a thin client running on a browser while a java server does most of the work?
IE: cretate the UI and it's controllers with JavaFX and have the bussiness/database connection/etc part run on a server?
Even if possible, would it be a complicated turnaround?
Based on the information you've provided, I wouldn't necessarily say that JavaFX is a good fit, but on the other hand I would not worry about the load times. My rationale is: The bad thing about JavaFX is that you have an additional tech requirement for your clients (JVM) and require some form of installation (even if it is just an applet). Those won't be a factor for HTML5. JavaFX has benefits over HTML5 if one of these cases is true:
1) You have complex controls and/or a lot of user interaction with the UI
2) You need your application to be really flashy, e.g. by incorporating animations
3) You have a complex business logic that you would like to execute on the client (e.g. because you had a previous implementation as a rich client)
'Some tables and simple controls' don't really fit here.
The reason why I wouldn't worry too much about the download time is that most users of an enterprise application will be using your app a lot from few different machines, thus caching should deal with that problem (plus an FX app is not going to be that large).
There is an interesting article on the topic to be found here: http://www.oracle.com/technetwork/articles/java/casa-1919152.html . Since it is coming directly from Oracle, you should of course take it with a pinch of salt, but I for one do agree with the general notion. The article also outlines some (subjective) experiences when switching to JavaFX.
If it's an enterprise app, and you already know that your users will have java installed on their clients, javafx is a good solution. If not, the downloading of the javafx jar can be quite a buzz kill the first time an app is run, as it's quite (understandably) large. I'm using it for enterprise apps, and the web start functionality works well.
And don't forget, if you're using jdk 7, there is a javafx packager which will create a single file installer/run-time for your app. I can't provide a lot of detail for that as I haven't bothered with it yet.
Related
I've heard the Google Web Toolkit isn't that good for web sites with more than 5 pages and a common layout. Is that true? We have at least a 100 subpages and a common layout defined in CSSes. Today were using PHP but we will move to a Java front either Spring MVC or GWT. We're using som jQuery AJAX and other jQuery components like a jqGrid. We also have some .swf-films and fusion charts. Will opting for Spring combined with GWT be a good choice or is Spring MVC with a jQuery library a better choice for us?
It's not true now. Earlier GWT versions really had some issues with scalability (e.g. problems with JS code size in IE - http://code.google.com/p/google-web-toolkit/issues/detail?id=1440), but since GWT 2.0 you have no limitations here.
Moreover, latest GWT versions support functionality for splitting projects to the parts that may be loaded dynamically when they're needed. Please refer to https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting to learn how it works.
Take into account also that since Spring is Java, you have possibility to share classes between server- and client-side. Plus Java has very good support in IDE - all kind of refactoring will be available for you (it is not so convenient in case you use jQuery).
So Spring+GWT looks more preferable choice.
GWT is not a universal framework for building just a any webapp from scratch. It is very useful when you have a lot of complicated logic on client side, (image editing, real time collaboration, diagram drawing, games , complex reports building and etc etc). But all of this can be done without GWT.
GWT can be used when:
your team hates/dislikes JS (and is unable to build nothing complex with JS, just because they hate JS)
your team is quite experienced with Java
your team understand how all this browser related stuff works (HTTP, JS, DOM , CSS and etc)
in this project there are will be a lot of logic running on client side
I've seen quite a few big projects built completely with GWT. Some of them should never used GWT, because the were no reason for them to use it in such way. For most projects it is enough to use GWT only for some part of application.
The choice depends on your team and the project you are doing. If your team can't really see what benefits GWT will bring to the project, then you shouldn't use GWT.
Our enterprise-level application utilizes both and we're quite happy with the results. GWT is a powerful toolkit which lowers development time by orders of magnitude. That said, there are still things that GWT either doesn't handle all too well or just plain isn't suited for (and that's ok... that's why Spring MVC lives nearby). We have GWT-RPC hitting Spring services directly and it works incredibly well.
Our project though is a true webapp, not a website. We use a unified design which spans all "pages" (using a DockLayoutPanel and swapping out just the center makes this super easy).
IMO, whoever told you that GWT isn't good for consistent design across numerous "pages" is nuts...
I think any assertion that GWT (or any other method) lowers development time by an order of magnitude has already been debunked by Frederic Brooks in a time when shoulder pads and Jan Hammer's synthesizer were fashionable: http://en.wikipedia.org/wiki/No_Silver_Bullet.
But seriously, if you're a PHP shop, moving to 100% Java would be a huge investment, and not to be taken lightly.
On my experience of GWT, my only bad experience was with GWT compilation slowness due to lot's of permutations. Our application had more than 20 languages to support, which multiplied by 6 for browsers specific result in 120 permutations, which proved to get horrible performance.
But this is not a real bug issue, because you'll mainly use the dev mode, with instant code update, and you can have special compilation unit with reduced set of browser and language (even one language and one browser => one permutation if you wish).
So in my case, using Jenkins we made the big prod target full build nightly, deploying on a QA platform so that the QA team test every browser language combination. And on every commit a reduced build (1 browser and 2 languages in our case) was deployed on a dev validation platform.
GWT is definitively a great tool for large app. ;)
I'm going to develop a web application using SmartGWT. I've heard about Vaadin framework. I wonder what is the best to use?
My application will be used by ~500 users at the same time. And I need high response performance and high security control. I won't need dozen of pretty widget just enough to be able to use pretty tabbed pane and table. So what is the best choice regarding my needs?
Edit :
I'll also need a tool to export table content to Excel format (like in Google Doc SpreadSheet).
ps : already check this one Should I use Vaadin Framework
I looked into both these frameworks, and others, and decided to go with the core GWT widgets. You desire to have high response performance will be difficult with Vaadin since it sends almost everything back to the server. And if you don't need super fancy widgets then the core widgets (plus some incubator/3rd party ones as needed) should be fine. I didn't get deep into testing SmartGWT, but it seemed to really tie you into their framework (making it difficult to use core widgets as well) and I read about difficulties when starting to do things different than the showcase examples.
Good luck!
If you write your Vaadin application properly, it will be performing perfectly well (check this one: https://vaadin.com/wiki/-/wiki/Main/Optimizing%20Sluggish%20UI).
If you know SmartGWT, use it. Also, if you have no experience with Vaadin, use SmartGWT. It might take you a lot of time to learn Vaadin (it requires some practice after one is able to create well performing application). The biggest problem of Vaadin that it is very easy to write slow application - because everything seems to be so easy and one tends to use many components and so on...
I would like to find a good (up-to-date) Java Trail type beginning tutorial on Websockets, with both Javascript client code and Java server code (that actually works). On the server side, if all I have to do is create a simple socket server or something like that, please tell. I have so far found nothing (although I've googled for hours) that provides the essential basic information like this (except on the client side, which is apparently very easy).
I'm not interested in using existing Websocket server systems (other than starting with a simple copy-paste from a simple tutorial). If you're interested, I'll tell you why below.
I have an open-source project that's been begging for HTML5 since long before it began (from its initial conception many years ago). Getting the two-way communication from Websockets as opposed to long-polling, forever-frames etc. looks like a winner to me. The current version of the (framework) software is HLL "light" - with my typical emphasis on not dragging in extra code. It uses Java SE only, although I intend to build version(s) using EE communications. I can at present easily install the whole framework with room to spare for application components on small devices like cell phones.
I want minimum code.
I pride myself on understanding all the code in the system.
I think it's death to a new open-source project if you have to tell people who want to try it that they have to download and install all sorts of other open-source code to do it.
I don't want my code subject to changes in somebody else's code.
This really shouldn't be all that difficult - if I just find the right documentation.
UPDATE: I no longer need a simple tutorial on websockets. I'm well on my way to having built a production class websocket server and have a very nice browser-based client to use for testing. I am now building a non-browser-based client to go with it. Building a multi-client websocket server that implements the full standard isn't simple, btw. (In hindsight - it's no wonder I didn't get any answers.) And if it's going to work as a stand-alone server for browser-based clients, it needs http (to provide the web pages at least) and other stuff. Not a project for the faint of heart or someone with little time to put into it.
Since first posting, I've been building my own WebSocket server. Dreams that all this would be simple quickly passed. I am however, getting close enough to mention the word "release" as in free Beta for anyone who wants a websocket server. (Notice I'm just "mentioning" the word - I'm still at least a couple of weeks away.) It's a multi-user server that's light-weight and screamingly fast. I'll eventually add http support so no other server will be needed for delivery of web pages (WebSockets are upgraded http connections anyway). I'll also be adding HLL functionality. First thing about that is that it will simplify application. Even though I've worked consistently to maintain "light-weight" status, this whole combination has been a life's ambition and I believe developers will find it amazing for building anything from simple and direct to large scale complex, distributed, intelligent systems.
I've used the most recent version of the standard, which is the final draft version, and will probably be very close if not the same as the final standard; version 1. So far, it works with Chromium (Chrome dev) and Firefox. There is however, apparently some code in their WebKit that provides support for other browsers. I haven't tried that yet. With the browser, I've so far made the connection and pass text messages (large and small) back and forth. That's all I've discovered so far that the browser handles. I take it support for very large text "messages" would really only be used for file transfer in conjunction with HTML5 local storage capabilities. I haven't tried that yet either. Binary transfers will likely be connected to HTML5 streaming video and audio at some point, but I haven't run across any mention of it so far.
I'm currently working on a Java client that will support the full standard, including pings and binary transfers, file transfers - the whole ball of wax. Most of what I need has already been built for the server and its "echo" application which includes message sending just like a client. I will then revisit some of my earliest work to generalize in a nice way when adding the new functionality. Having one or more Java websocket clients in applications will be a good thing in many cases, I think. And it'll give the the full capabilities for web browsers as well, whenever they're ready for it.
I also know that Opera is quite popular among HTML5 enthusiasts. I actually started using the version of the standard that they support so it shouldn't be difficult to add it. (Just fooling around trying to find my way - and got the stuff specific to that version working.) I'm seriously tempted to spend the time putting the support in for that version even though it should become totally obsolete within a few months. It's just that Opera is very good on the other HTML5 stuff and there's a large crowd of enthusiasts using it. On the other hand, they mostly work on the browser-client side, and I don't know if they'll get involved much on building server-side applications.
Blog articles related to my work on WebSockets.
WebSocket Server Demontration, SEPTEMBER 26, 2011
WebSocket Demonstration on Microsoft Internet Explorer, NOVEMBER 16, 2011
WebSockets with Apache Tomcat and HLL, JANUARY 12, 2013
Background
I'm at the planning stages of a DIY project that'll help me automate some hardware at my house. It's probably also worthwhile to mention that I've got almost no experience with web-related development.
The Basics
http://img7.imageshack.us/img7/4706/drawingo.png -- I can't seem to embed the diagram.
In order to simplify management, I want to implement my UI in the browser.
The meat of my application will reside inside a Windows service or Linux daemon; this does not mean, however, that I'm after a cross-platform solution -- I'm not tied to any particular platform, so I'll pick one (probably based on the responses that I get) and stick with it.
I would prefer to use "free" tools (e.g., LAMP/WAMP), but it's not a deal breaker.
It would be nice to be able to communicate back to the user that some action is in progress (I think AJAX would be one way to go?)
Questions
The only thing that's not entirely clear to me is the implementation of step № 3. I'd like to hear possible implementation ideas (on Windows or Linux) as to how this should be done. Hopefully some of you can share how this sort of thing is done in the real world.
Miscellaneous
As always, if there's a problem with my thinking, please point it out!
There are many people better qualified to help with step 3 so I'll leave that to them.
My question is whether is you are looking forward to learning the mess of web technologies required for the front end or consider it a necessary evil on the way to what you really want to accomplish? If the latter (and assuming you are working in C/C++) consider taking a look at WT. It's a toolkit that makes the developing the web interface seem more like a desktop gui while handling much of the ugliness for you. It could potentially cut a lot of time off your development.
I'm having trouble deciding if I want a project of mine to be web-based (as in a web-app), desktop-based (a desktop application), or a desktop application that can sync or connect to the cloud.
I don't know if anyone else would have an interest in this application, and it's only going to be for me, so I'm leaning toward desktop application. If, for some reason, I finish it, release it, and people actually like it, I might see about making it sync to the cloud as well (think v2). But I'm not sure how hard it is to make such a radical change, and I don't want to end up with something good that is useless because I made a poor choice before I even started the project.
Is there any sort of guidance for this? Any rules of thumb or best practices? Any personal experiences?
If the language matters, I'm thinking about Java simply because I'm most comfortable with it, and it would easily allow me to share it with my friends for testing and if I get stuck and need help from someone else in person.
I generally ask a few questions:
Can it even be done on the web? Something I did not too long ago involved an image editing component, and had to be a web app. It involved much pain to get this work, and a desktop app would have been a far better way to go.
Will I need to access it from anywhere? Yeah you could load it up on a thumb drive, but the web is far more feasible in this case.
Will there be multiple users? This could go either way, but "long tail" stuff usually means web.
What tech do you want to use? The latest and greatest WPF based UI? Desktop (yeah yeah, silverlight, let's not go there ok?). The brain dead stupid easy user management of Django or others? Web.
If it were a web app, will you need to worry about common attack vectors like SQL Injection, XSS, etc? A desktop app has its own issues here too, but tend to have less exposure.
How resource intensive is it? Will 10 users kill performance of a web server?
Versioning on the desktop can be a pain, whereas with a webapp everyone is on the same version. This can bite you though, see the New Facebook user pushback.
EDIT:
Cost can be a factor too. A web app with a database backend typically means a web server. If you want to stick with, say, the Microsoft Stack, you'll need licenses for SQL Server which can get pricey. Open source is cheaper, but may not be an option in all cases. "Serving" a desktop app is generally cheaper.
If you release as a web-app, you won't have to port it over. You'll also have access to it wherever you go.
I base my choice on the GUI mostly. If the GUI is going to be complex, and (needs to be fast or will have aspects of it that will take a lot of time to process) then I will go with the Desktop. If it is simple, and will always have small data sets to work with at once, the I will go with the Web.
I have worked on an app that was made as a web app, when clearly it was better suited for the desktop. It was a massive failure. I don't know HOW customers put up with it, cause I certainly wouldn't have used it. The desktop version (which took over 6 months to re-write) blew the web version out of the water.
That being said, I have seen some nice web apps.
All I can suggest are several factors that would be relevant. How you determine the answer and weight for the factor is up to you and other circumstances:
What is your audience? Do you have any control over them?
How complex are the interactions you expect to implement?
Do you require near real-time data updates?
How often do you expect to update the application after the first release?
Do you expect a well-defined set of client platforms, or can you not predict that?
Note that your choices also can include a Java WebStart application, which mitigates some of the disadvantages of a typical desktop application.
I'd say that most applications should be desktop-based. The advantages are faster and more fluid apps.
You should only create a web application if there are obvious benefits from it, like access from everywhere. (If that's necessary for your app.)
A downside of web applications can also be that it is dependent on the developer, if you quit supporting it all your users (if you'll have any) can't use it anymore. Furthermore, there is a chance that users are not willing to store their data online.
Ultimately it depends on what kind of an application you want to write. Even if you create it as a desktop-app, you can later on rewrite it for the web. Often a 2.0 version of software needs almost complete rewriting anyway.
Sometime web can be good and sometime not. We are in a new wave that go in the web but do not forget few things:
GUI in web is more complicated because of multiple browser
People who need to work on your system might not like working the whole day in a browser
Web can be slower for some application (image editing, hard job that require a lot of CPU)
Rapid Gui like Visual Studio for winform are faster than for web
But web has many advantage in the deployement and in the portability. If your system is well structured you could make both or change to one to other later with something build with MVC. Just change your visual and you will be fine.
If this were an application to be used my multiple users, with shared data, you're probably going to want a server anyway. In that case I'd lean towards a web application.
Otherwise you've got the complexity of syncing data between the desktop and a server.
Two important questions not on the list so far:
Will the first version have any features that need lowish-level access to hardware?
Will future versions have any featuers that need lowish-level access to hardware?
It's pretty easy to answer the first one, but giving the second one some thought can save you some headache down the road.
My default choice is to go with a web solution, as it's easier to deploy and generally multi-platform. The only time I go with winforms apps is when there are pressing security, performance, or functionality issues that require it.
Previously you'd have written a desktop application, as tool were better for that and you'd have written it faster. People used to want web apps, but always ended up with desktop.
Nowadays things are different, you can write a webservice just as quickly and easily so there's no reason not to go web-based.
The advantages of web-based are flexibility, scalability and ease of deployment. It won't be as responsive as a desktop app could be, but that's not so much of an issue if you think about your design.