I am planning to make an application that has views with complex forms and logical validation on the client side. I plan to use AJAX for submits and have some visual appeal.
I want a recommendation from those who have experience developing with Bootstrap and/or CoffeeScript and Vaadin. I have two options:
Using Bootstrap / CoffeeScript and some framework for the server site, such as Play Framework, Rails or Django
Vaadin
The criterion that concerns me is related to the complications that may arise in the client side JavaScript and/or HTML5 validation as well as in CSS and HTML code to be written using Bootstrap. Is it worth using CoffeeScript over Vaadin in a practically ria app? I see that there are many who have chosen Bootstrap and I'm sure they have their reasons.
Help me with the decision. Some relevant documentation could be helpful, too.
Vaadin
Vaadin in an amazingly good tool for building interactive desktop-style web apps developed in pure Java and delivered via regular web browsers.
Benefits
Vaadin 6, 7, and 8 apps run entirely on the server-side. The JavaScript library automatically installed by Vaadin into the user’s browser window simply:
Draws on-screen whatever the server-side app tells it to.
Feeds user actions (clicking, typing, and so on) back to the server for the app to consider and respond.
So there is no "logical validation on the client side" or "html5 validation", at least not from the Vaadin app developer’s point of view. The Vaadin framework may do so under-the-covers in its internal implementation, but that is none of my concern as a Vaadin app developer. That’s the core benefit of Vaadin: I don't care how Vaadin gets my forms onto the user’s screen. As a Vaadin app developer, I am not writing any JavaScript, HTML, DOM, CSS, or AJAX. Just pure Java.
The style is similar to Swing: Instantiate a layout (a form), add labels, add buttons, add fields, add other widgets. Attach validators as needed. Nest additional layouts, for complicated forms. All of that executes in memory on the server-side, all in pure Java. Finally tell the layout to show itself. Poof, like magic, Vaadin tells the browser to display a likeness of that form.
If you want to develop desktop-style business-style apps that happen to be deployed through a web browser, Vaadin is a wonderful tool.
Trade-Offs
Trade-offs include:
Lots of memory and CPU usage on the server-side.
Giving up control over the HTML/CSS/JavaScript.
Scaling
Your web app lives on the server, not the client. All your business logic, the users’ entered data, the internal representation of all the users’s forms such as row items in a table, all this lives on the server. Multiply that by number of users. This means a Vaadin app can demand much memory and CPU usage.
That may limit scaling up. But given 64-bit Java, multiple gigs of memory, and multiple cores on even the lowliest of machines such as a Mac mini, scaling-up is likely an issue only for the largest/busiest of apps.
And even in those rarer of large/busy app there may be ways to handle scaling in Vaadin. All of the app lives in a Servlet Session. Some web infrastructure allows such session state to be moved between servers or even persisted out to storage to be picked up by other servers.
Or your app may scale well. Simulations with 11,000 simultaneous clients have been done. See:
Vaadin Scalability Study - QuickTickets (company blog post)
Scaling with Vaadin and WildFly Webinar with Arun Gupta (video presentation, YouTube)
Control Over HTML, CSS, JavaScript
If your team is more comfortable or experienced with conventional web app architectures, then Vaadin may not be for you. In Vaadin you write your app entirely in pure Java, and Vaadin translates that to HTML, CSS, and JavaScript automagically.
You can tweak the CSS a bit. And even without touching CSS, Vaadin’s "themes" (Valo, Reindeer) give you much control over colors, sizes, and fonts if you wish to override the defaults. But know that Vaadin is in the “driver’s seat” in generating the HTML & CSS; you are just passenger who is allowed a small bit of “backseat-driving”.
If your goal is something other than developing desktop-style apps, if you want to take full control of the HTML/CSS, then Vaadin may not be for you.
Updates
Vaadin 8 released
On Feb 22, 2017, Vaadin 8 was released. Biggest enhancement is re-written data model and data binding API utilizing modern Java features, such as generics with type parameters and lambda expressions. Also, more efficient with memory and CPU.
Vaadin 7 released.
While largely the same architecture as Vaadin 6, 7 is better than ever. See: What's New.
I would go with Rails 3.2 + Bootstrap + Backbone.js, the stack we use here.
Rails: Nice community, solid platform, very easy to develop for, can deploy to Heroku (God bless Heroku).
Bootstrap 2.0: HTML5-compliant, nice out-of-the-box features, good community (just look at their github page), sensible js plugins.
Backbone.js: Very nice for client-heavy applications, plays nice with the rest of the stack (specially jQuery), provides a good user experience when used right, unobstrusive. Specially good for dynamic forms since you can refactor a lot of code using specialized views (autocompletes, tables with multiple items, related select boxes, etc.).
As for documentation, both Rails's and Bootstrap's are top notch and you can find a lot of books about them. Backbone.js, despite its large user base, is more specialized, but you can still find a lot of good screencasts and e-books in the Net (I recommend the works of peepcode and thoughtbot).
Good luck with your app!
PS: Another good point of using Rails is the set of gems and addons you can use. Full text search? Sunspot. Audit and Versioning? PaperTrail. BDD? Cucumber. I suggest you checkout the Ruby Toolbox site.
Related
I am working in a bank on online-banking solutions all my programming career, and online banking has one feature which is distinct from other web sites - it doesn't provide an admin page for users(a page where they can add web-pages, add content, edit articles). And indeed people only need to see information about their balances they don't need to edit that web site. Because of this I never used any CMS in my life, when it was needed to add a page with a new service, me and my colleagues just just manually created a new file.
But I am thinking right now on my own company, which will make web sites for all sorts of people. But it implies that at some point there will be a customer who will ask not only for a web site but also for CMS to manage that web site. And this is a really weak point for me.
I am using Java web frameworks, currently two of them: wicket and stripes. And I am afraid that if I will use some kind of CMS then I will not be able to use java web frameworks(wicket, stripes).Just to clarify I want to code all the logic by myself, I don't need precooked CMS components, I just need means to add, delete, modify pages.
And I am interested if there exist any truly free java based CMS which will allow me to use wicket or stripes java web-frameworks.
There are hundreds of CMS products in the market nowadays and each of them has got pros and cons, each developer may have their own preferred choice. If you ask 10 developers you will probably end up with 10 different answers. It is always gonna be a hard decision for developer who just start learning CMS.
A good start point I recommended is CMS Match which let you search, view and compare different CMS products. For java based CMS, these are some popular choices:
Alfresco
Apache Lenya
Hippo CMS
Liferay Portal
OpenCMS
Check out the horizontal comparison from CMS Match here, I used to study/work with Hippo CMS and Liferay Protal, both of them support all major web work framework like Spring MVC, Struts and Wicket.
You could use Wicket and Stripes in conjunction with Content Control to extend functionality, though not within the CMS.
Content Control has been setup to work with Rhino (JavaScript style programming, server side, developed by Mozilla) - so if you have JavaScript you can develop on top of the CMS that way.
Or just use Velocity to manipulate content.
Content Control is a freely available open source CMS with a nice API, inline editing (with code highlighting) of templates, scripts and CSS, versioning on all assets and lots of other nice development features.
It's not Wicket and Stripes, but shouldn't feel terribly unfamiliar. We'd be happy to help if you need some help to get started.
The company I work for has a powerful Java based server component framework for interacting with special control systems.
We have a UI framework but this is also Java based. A customer can use a Java Applet to access control information etc.
I've recently started working on a rich JavaScript API to access this control system information remotely. It's currently a prototype. It's nice because anyone who's familiar with JavaScript can access our Components remotely. So far it works really well. I've written some prototype applications that use this API. This gave me an introduction to jQuery - great! I've also added the ability for the JavaScript API to make RPC calls to Java as well as a session based Component architecture for when you really need something held on the server.
So far so good. I have to admit though that I'm not really a 'web developer'. I've never used Structs, Spring or any of the MVC based architectures for serious Enterprise based web development (I AM very familiar with design patterns though). My background is application development.
I'd like to know from the pros whether this is the right approach or whether I'm missing anything. Someone I work with has created a really neat Server Side Include architecture. However, I'm wondering now whether this is really necessary? After, I think I can create just about anything using my JS API and jQuery. Should I consider any other 'server' based architectures in this new age of open web apps?
As far as browser support goes, I'm not concerned about the older generation of browsers (please no lectures here, the old technologies we've got will do for IE6 and alike).
By using this open client side technologies, I'll be able to write sophisticated open web apps. Very little server side code will be needed in reality because of my API. I'll be able to take advantage of HTML 5 features etc. But am I missing anything? Should I be considering other server side based Java technologies like Server Side Includes? Am I too client focused?
Well there are four ways to create modern RIAs: HTML5/Javascript, Java Applets, Flash/Flex and Silverlight. Only the first two are open.
Applets are a nuisance and not really liked by people. Personally I'd go with HTML/Javascript.
Since you are a Java shop I'd recommend going with GWT for the following reasons:
It's open source with business-friendly license.
It creates minimum-size browser-optimized javascript.
It's actively developed and used by Google. This is a guarantee that it'll be supported for some time.
There are a lot of developers with knowledge of it.
It has good documentation and very active user group.
I'm sure there are many opinions on this, but my take is that with HTML5, faster Javascript interpreters, client side persistent storage, etc. it makes it pretty compelling to put all the UI application login in the client (browser), and just use some form of RPC (with JSON serialization) to the server. Therefore templating engines, SSI, or any server side generated markup is no longer required for interactive applications. It's still fine for semi-static documents. For that I use sphinx document generator.
Fast-forward two years, and you now have TodoMVC at your disposal to help answer this question. GWT is still mentioned, though as far as server-side technologies go, The Holy Grail is probably what you're looking for to maximize code reuse on client and server.
We currently have a 2-tier Java Swing application sitting on top of MS SQL Server 2005. All the business logic is in the database. The client is quite old (and not very friendly), and for reasons of performance and scalability, we've already started porting some services to a middle tier in Java.
However, we still have a number of short and long term goals:
Pick a technology stack for a new front-end
This isn't easy - I can see everything from a web app at one end of the continuum to a traditional desktop app at the other being viable choices. The current front-end isn't really complex (mostly form-based), so I can see web/AJAX fitting, but it's an area where we don't know what we don't know.
Stacks on my list are:
Eclipse RCP, Netbeans RCP
Flex/Flash, Silverlight, JavaFX
Pure Javascript frontends (Sprout Core, Javascript MVC, ...)
Java-based Web frameworks (Wicket, JSF, ...)
Find a way of making the current application perform acceptably in a remote situation
We have some clients who resale our app to smaller clients and need to be able to remotely deploy it. Due to the 2-tier nature of the current architecture this leads to terrible performance (for example, calling a stored procedure that returns 18 result sets). We've used a Citrix solution in the past, but no-one likes that approach. Tunneling JDBC through port 80 also sounds like a bad idea. I was starting to wonder if there's anything that could use a X-Windows like approach to remote just the GUI part.
To simplify development and leverage your experience in Swing consider using Vaadin for your frontend. It is a Java framework for building modern web applications that look great, and perform well. All the code is written in Java and looks very similar to Swing.
As far as overall application architecture I would advise multi-tier, service oriented architecture. The best way to do it is by using Spring framework with Hibernate for database access.
If you want to easily redeploy your application, for an update, security reasons, etc. and if you want your application to be it to be accessed remotely, you should really consider a web based front end.
Plus, this way, only one app, your web app, will handle connection to the database, so no JDBC tunneling or whatever.
Concerning the best framework, it depends on your team knowledge, the way your application will be used (more or less javascript), etc.
We've just gone through a very similar evaluation process as we're migrating a legacy application.
For us the biggest deciding factor in what front-end framework to use was the prior knowledge of the development team. We wanted something that everybody would be comfortable with immediately. We had a couple of the senior developers that have worked with X or Y, but the framework that everybody knew was Swing.
In the end we decided on the NetBeans platform using RESTful webservice to communicate with an EE server.
As a bonus you can get your NetBeans platform application to deploy as a Java WebStart application, which means you get the benefit of not having to worry about individual installations.
If the frontend is mostly form-based, I would stay away from Flex. Flex is great for some applications (I'm using it for a canvas based application), but the form components of Flex has some usability issues. They just don't work like you expect from todays web. (like missing support for mousewheel, typing in dropdownlist only take first character into account etc.)
Assuming that you are going to force all your clients to install a new middle tier, I can't think of an argument against making it a Java web app. As already mentioned you have the benefit of controlling all access into your platform over HTTP, which allows easy resale, just with firewall configuration. There's no reason you can't make use of Javascript within a web front end, you may be interested in DWR, which allows you to interact directly with Java objects via Javascript. I've used this before to add some simple Ajax interaction to a Spring MVC webapp.
The reasons I like this approach, you're already migrating code into Java middle tier, so
Already imposing Java server hardware cost on clients, hosting app server / web server is comparable
Already have Java expertise, can be leveraged with DWR
Can use as much/little Javascript as appropriate (I've used DWR with IE6, Firefox 3, Chrome)
I think you're right to be wary of pushing too much functionality to the client, I'd go for as thin a client as possible. The only reason I'd look at the first two stack choices would be if you have some developer expertise in a particular area, and not Java webapp/Javascript.
I'd suggest to create a short list of candidate frameworks and create a small test application with all of them. This way you will get a sense of good and bad aspects from all of them and also get a picture what the community activity and documentation is like for each project (there is a lot of variance on those).If you end up doing this I hope you'll include Vaadin in your short list, I think it would fit you very well. If you have any questions just come over to our forums and we'll help you to get started.
I am going to create a Java EE based project, in which lots of GUI work is involved, like creating tree and drag and drop of objects (like routers and switch) kind of thinks.
I would like to know if there is any open source available, with whom I can do rapid Java EE GUI development.
The JBoss Seam framework allows you to generate a whole application.
With JPA,EJB and JSF for presentation layer, You can choose between Icefaces and Richfaces as JSF component library, both support trees as well as drag and drop.
Java EE itself doesn't really address this kind of UI activity. If you're thinking about drawing a network diagram and dragging and dropping items on a canvas then that's happening in the client, perhaps a browser. Java EE is pretty much a server-side framework, great for dealing with databases, queues and other enterprise connectivity, munging data and rendering HTML.
For traditional form-based UIs extension such as JSF give you lots of nice widgets for trees and other such UI structures but doesn't attack a "drawing" application.
A few years back when worked on an application of the kind I'm guessing you're thinking about, we used JavaScript/Dojo in the Browser to render the UI and Java EE on the server, but we did a lot of manual coding - I don't know whether these days there are better frameworks. I'd recommend exploring client-side UI technologies to use in conjun ction with your Java EE server-side stuff.
I would suggest ICEfaces which is an implementation of JSF but process all requests via AJAX. It also support drag and drop feature and other components just like desktop gui such as treeview, datagrid, radio buttons, combobox, menu, richtext box, process bar..., check out its components here: http://component-showcase.icefaces.org/component-showcase/showcase.iface
Checkout Grails, which brings the speed of development known from Ruby on Rails to the JVM.
For trees, drag and drop etc, I would use one of the many JavaScript frameworks, like Dojo, Prototype+Scriptaculous, jQuery+jQueryUI+plugins, YUI3 etc.
I'm asking this question because I'm having some difficulty choosing a framework (or selection of technologies) that I can learn and use for developing a web-based UI for a small Java application:
For background information relating to the app I'm developing please read this question:
So, developing the Java application is going ok and now I'm in a position where I would like to develop a web-base UI for it.
The application and database (MySQL) currently run on a Debian Linux box, as such I've decided that it would sense to use Tomcat to run the Web App. The Web App is to serve the following purposes:
1. Manage the execution of the App by CRUDing data from the MYSQL database.
2. Display status information about the app (i.e. what orders it's placed, what orders are pending, etc.)
3. Produce on demand reports on stuff like the running profit and loss, historic and realtime prices and pricing analytics
So far so good now here's the problem:
There are a bewildering number of choices for how to develop the UI, to name a few I've looked at:
JSPs + Spring MVC
JSPs + Sping WebFlow
JSPs + JSF + Facelets
Wicket
JSPs + JSTL
etc, etc...
The choices seem endless. Is there's a clear industry standard for developing web based UIs using Java related technologies? If so what is it? Ideally I would like to learn a framework which I can use in the majority of real world jobs (and preferably one which can be used from Eclipse).
Thanks and Kind Regards
Personaly, I prefer another approach,
I would go for Eclipse of course, Spring (or other IOC container), Hibernate / JPA + JAX-RS or JAX-WS for the server layer, but not nessecarily JSF / JSP for UI.
For presentation layer, I would rather go with Flex, GWT, or a JQuery in an SOUI approach. (the service layer returns incremental updates in the form of XML or JSON, I swore not to mention the term AJAX)
Your service layer would serialize partial object graphs by demand from the presentation layer, which will act as a disconected client (work on an "offline" dataset , and update dirty on demand)
But that is just my wet dream, and in my current project I'm stuck with Spring MVC, and JSP + JSTL
I would give Jboss SEAM a test drive, just because Gavin King is behind it, but I think its JSF based.
I don't know why I don't see JSF as a SOFEA / SOUI approach, as JSF and AJAX go together well, but for some reason, JSF didn't win my enthusiasm as much as the above suggestions (Flex as a favorite)
See my related question: Web architecture: MVC, Lazy initialization, Data transfer Objects, Open Session In View, is there a consensus approach?
Is there's a clear industry standard for developing web based UIs using Java related technologies?
Well, Sun's Java EE standard is Java Server Faces (JSF) but the version 1.x of JSF is IMHO a kind of failure. This explains why they are so many alternative out there. But NO, there is no clear winner.
Ideally I would like to learn a framework which I can use in the majority of real world jobs (and preferably one which can be used from Eclipse).
Actually, Matt Raible has done very famous presentations on presentation frameworks that you'll find in Comparing JVM Web Frameworks Presentation (the latest version goes beyond Java frameworks only). Really, have a look at both of them, this is very, very good material (with real life metrics).
Personally, I'm a JSF 1.x skeptic so I would not go in this direction (there isn't lots of demand for JSF in my country anyway) but rather choose an alternative. I think that Struts 2, Spring MVC, Stripes (this one is my preferred one), Wicket (this one is getting more and more attention) are all decent choices, they'll all get the job done, the 2 first one being I believe more asked on the job market (but not the smartest). For the final choice, I'd follow Matt's advice: Eliminate, Don't Include. If the popularity on the jobs market is an important criteria, then I guess Stripes and Wicket will get eliminated. If configuration verbosity is a concern, Stripes wins. If you're looking for a kind of Swing experience, Wicket is your friend.
Now, I need to mention that the freshly released JSF 2 and CDI (JSR 299) should be a big improvement (according to the people who worked on it). As I said, I'm a JSF skeptic and I need to take a second look (because Gavin says so). But I still didn't so I can't say anything for now and I won't make any bet on the adoption and future market demand of this new version. But it's worth noting that JSF 2 with CDI should be a really new and different experience.