Which web framework or technologies would suit me?

Question

I had been working on desktop apps and server side(non web) for some time and now I am diving in to web first time. I plan to write a scalable enterprise level app. I have worked with Java, Javascript, Jquery etc. but I dont really love jsp that much. So is there any framework that focuses on developing enterprise level web apps without jsp.

I liked Wicket's approach, but I think there is a little lack of support of dynamic html in it and jquery(yes i looked at wiquery). Also I feel making wicket apps scalable would take some sweat.

Can Spring MVC, Struts2 etc. help me make with this with just using say Java, JavaScript, and JQuery. Or are there any other options for me like Wicket.

Please do forgive if anything above looks insane, I am still working on my understanding with enterprise web apps.

NOTE: If you think that I should take a different direction or approach, please do suggest!

Answer 1

Wicket's nature (component-based, server-centric state) makes it somewhat more rigid about your page structure. I mean, it makes it incredibly easy to 'ajaxly' switch one panel with another, but makes it more difficult to make changes that actually change the structure of the page. This may limit the dynamicity you can put into it, but helps a lot in maintainability, since it will also prevent many 'bad practices'. It's certainly possible to do anything with Wicket, some will be easier, some harder.

But, I think it will be easier for you to grasp, since it's programming model resembles the desktop's (event-driven, components, etc.).

Action-based framewoks let you manipulate your DOM in a adhoc fashion, letting you do pretty much whatever want. This gives you a lot more freedom, but it certainly has a cost. If you manage your state at the client, you'll have a whole set of security issues you simply wouldn't have with server-centric state. If you manage your state at the server, you'll have a lot more work synchronizing it with the client-side, since the framework won't help much. Since you have more freedom, it's much easier to make a mess.

And this will happen with Struts1/2, SpringMVC, and any other action-based framework.

GWT has its own category. Since you code in Java, it has all the static-typing advantages of the server-centric model, but since it runs on the client, you'll have the same security issues you have with plain Javascript. Since it's a component-based framework, it will make hide-show-replace really easy, but will also require a more rigid structure.

Every approach will have its downsides and upsides. It's just impossible for us to determine what 'suits you' better. The best we can do is to help you to make an informed decision. :)

Answer 2

I love Apache Wicket. This framework is very, very strong in MVC programming. While there is a bit of a learning curve, especially for those that like to mash everything into a single controller, staying with it is extremely valuable. What I like most is the clean separation of HTML and your Java code. No dorky inline tags, like what you'd do with JSP or JSTL, just your HTML/CSS/Javascript in HTML files, Java logic in .java files. Just like it was intended.

Answer 3

After having used Wicket for years in our company, we are moving away from it. We are favoring an approach that will create REST services and straight HTML/Javascript on the client side. I'm more of the server-side person myself, so I don't have too much insight into the negatives of our past approach. However, it is my understanding that entire pages are rendered on the server and transfered to the browser. In our applications, that leads to a lot of useless data transfer. Furthermore, we seem to be lacking the flexibility to do certain things that should be quite simple and turn out to be difficult because of our use of Wicket. Again, I am not the client-side person, and it's possible our Wicket stuff just totally sucks, so take my comments with a grain of salt. But if you had a Swing app, would you render Swing components on the server and then transfer them to the client or would you send data as light as possible to the client and let the client do the work that the client should do? In another situation, all the rendering on the server was adding significant load on our server that was already busy processing a high volume of incoming data. The additonal load due to Wicket came from things like sorting data prior to creating a table. Then when you want to change the sort order on a table, it re-renders the whole thing on the server and sends the whole page back to the browser. We started rewriting that application using JQuery/HTML, and this table component we're using is lightning fast to change sort order without any additional data transfer.

On the server side, I am falling in love with the RESTful architecture. While rewriting the above mentioned application it was so easy for me to test my business logic in the server by simply using curl to make HTTP requests. In order to test that stuff with our old architecture, I would have to use some server-side testing framework or expose EJBs just to get at the methods (or only ever test it via the Wicket application). Now, I am able to exercise the same exact calls that our web client will make just by issuing a single line shell command. Furthermore, now our services are exposed to customers in a way that can be more readily digested. Our customers won't need to learn Java/EJBs. They won't be limited to writing a webapp or stuck with whatever webapp we create for them. Any language our customers are familiar with that has the ability to make HTTP requests is fair game.

Answer 4

You could very well try your hands on GWT Lots of stuff on the net... See: Google Web Toolkit

Use it with a good IDE such as Netbeans or Eclipse(GWT gives support for eclipse)

Mixing everything with wont do much harm...but i personally advise try sticking to one library

Good luck....

Answer 5

I'm using NodeJS (2.x for stability) and MongoDB for my projects and I love it for the most part. Before that I used Django (python based), which I still love, but not quite as much. I have experience with servlets but I hate them mostly.

Answer 6

With Struts2(S2) you can avoid using JSP's altogether (free marker/velocity are also view options) further since you are comfortable with jquery I suppose you can stick with pure html with jquery (although the html files would technically be jsp's although without any jsp tags). You could then use the jquery getJSON call to get the data you need into your page. The data would come from a S2 action using the Struts2JSON plugin.

Answer 7

If you want to write an enterprise level web application you need to understand one fundamental principle. That principle is, your application will execute in the browser. You can use any server technology you want but you can't get rid of the browser if you are building a web application. What that means at the end of the day is that you can't get rid of Javascript, HTML or CSS because these are the technologies that your application will ultimately be implemented in.

That said, Wicket like all server side frameworks, abstracts away the "browser" part of your application as much as possible. Instead of you writing Javascript, Wicket writes it for you. Instead of you writing HTML, Wicket writes it for you. Instead of you writing CSS, Wicket writes it for you. You can write some of your own Javascript, HTML and CSS but any use of Wicket will write more for you.

I currently develop on a legacy enterprise application built in Wicket. This application is legacy because it has reached a point where simple client requests cannot be fulfilled using the Wicket technology. The developers are all Java developers and went with Wicket because it is supposed to be one of the better Java web frameworks. However after building the app and supporting it as the app has grown they've realized its more difficult to develop than anticipated. Now it has become very burdensome to develop and they are unable to meet some client requests. There is big money involved here so they are migrating to a RESTful application written in Javascript, HTML and CSS. The Wicket abstraction seemed to help at first, but this very abstraction turned out to be the source of the problem as well because you are at the mercy of what the abstraction will allow you to do in the browser.

This is not uncommon for companies building large scale web applications. Initially it seems easier to use a framework that abstracts the client technologies away. But typically this ties your hands too tight for enterprise level apps.

If you really want to control your application, you need to write it using the technologies that it ultimately executes in: Javascript, HTML and CSS. Rather than having a framework abstract those technologies away, you should learn them. Once you learn them you will be able to write enterprise level web applications that address concerns such security, state management and the like.

Check out these resources if you need a place to get started:

Architectural Style:

www.infoq.com/articles/rationalizing-presentation-tier

blog.jeffhaynie.us/mvc_is_dead.html

www.eweek.com/c/a/Application-Development/How-to-Architect-NextGeneration-Web-Applications/

How to write Javascript Applications:

developer.yahoo.com/yui/theater/video.php?v=zakas-architecture

andyet.net/blog/2010/oct/29/building-a-single-page-app-with-backbonejs-undersc/

jupiterjs.com/news/organizing-a-jquery-application

Answer 8

"I absolutely hate jsp". Consider using HybridJava - it was all developed out of that same feeling. It is much simpler than all the alternatives (even those that position themselves as "very simple"). Yet it overcomes those limitations that make people hate JSP.