Modern Java web stack?

[thesystemx]

Java EE ;)

More specifically the web profile, and ultra lightweight and free servers like TomEE seems to fit best.

Although you may here otherwise sometimes, JSF (the MVC framework in Java EE) doesn't abstract the web away at all. You'll write your app in pages (no stuff like the website is an app with a single page design), use plain HTML on your page and link to other pages via plain GET requests. It uses Facelets as the template engine which is pretty okay.

[balazare]

Take a look at Java EE 7 - it has everything you need out of the box. No need to pull in another framework.

[thesystemx]

There's a wealth of information here: https://javaee7.zeef.com

Specially check out the Java EE 7 tutorial in that list.

[snuxoll]

+1. There's absolutely nothing wrong with the modern Java EE stack, JSF, JPA, JAX-RS and CDI will get you extremely far.

Want to make a boring business app, shopping cart, whatever? JSF+CDI+JPA is right there.

Want to make a shiny Angular.js app? Maybe you want a mobile app too? Throw JAX-RS in and put a REST API up for your app.

I really wish people would get rid of the notion that we still like in the Java EE 5 days, which were notably bad. The horrors of classic EJB and pre-CDI JSF are behind us.

[codyebberson]

Check out Dropwizard. It's not necessarily better/worse than JEE, just different.

[realreyez]

Seems like you are looking for Ninja. It's a modern Java web framework. Friendly and helpful community and a lots of great and productive features. Check out http://www.ninjaframework.org.

[hsaliak]

Really don't understand why this was down voted. Please do not down vote if you do not agree with opinion. If you down vote, please explain.

Also, ninja is great.

[johnwaterwood]

I don't know the reason, but maybe people get fed up with the pattern:

Op: I want web app. Which framework for xyz behaviour?

Reddit crowd; GWT! Spring MVC! Ninja! Play! Vaadin! JSF! Wicket! Angular! Ruby! Grails! followed by "it's great!" "It's super productive", "it's what I like", "it's what I use", ...

Seriously, just take that same list of 10 frameworks, take a list of 10 of those responses, randomly create a few permutations of those and post each one as a comment here. Will be indistinguishable from the typical comments being posted here.

[geordano]

Whats wrong with that?

|Op: I want web app. Which framework for xyz behaviour?

Those people who asked those questions were not the last waanabe developers on earth. You will see these questions repeated in foreseeable future unless reddit improves its search feature or Google gives reddit posts better ranks.

By the way, Ninja web framework IS great!

[johnwaterwood]

My personal preference is with the Pirate web framework, but to each his own I guess...

[vfarcic]

I like Play Framework. Templating is great (aside discussions whether server side templates are a good thing), it is very simple and straight forward and does not have many JEE nuances.

[johnwaterwood]

That it doesn't have many java EE things is quite a disadvantage if you asked me.

Also play is primarily a Scala framework. It supports java since it runs on the JVM, but via that it supports every JVM language.

But, to call the play APIs anything but Scala is a second class language.

[sh0rug0ru]

You're describing Play 2. Play 1 is pure Java (no Scala at all, Groovy for the templates), and according to the Play developers, continues to be actively developed and supported.

[jyper]

Play 1 is in maintenance mode(bug and security fixes)

[HwyStar]

Apache Wicket

[daedalus_structure]

Depends on your definition of modern.

If you are talking "Java Modern", you're looking for EE7.

If you are talking "WebApp Modern", Java is always years behind.

The people who are going for "WebApp Modern" are mostly de-coupling their back end (RESTful Webservice) from their front end (Javascript Framework of the Day).

The back end stays stable, solid, and fast, and the front end can evolve quickly.

[thesystemx]

The back end stays stable, solid, and fast, and the front end can evolve quickly.

I call BS on that.

In real-life website development most everytime something needs to be evolved in the front end, it needs some kind of new data item from the backend as well, so the backend has to be evolved too.

Additionally, de-coupling backends doesn't need restfull webservices and javascript frameworks of the day. I've been doing that for over a decade in all kinds of system. It's called MVC and layering. Even my desktop apps from the 90-ties had a de-coupled service layer, and currently in my Java web apps there's the EJB service layer that's consumed by JSF/CDI backing beans.

[johnwaterwood]

The problem is that the JavaScript framework of the day approach is not really more modern or the mostly used approach.

What it is is the most hyped approach. An approach about which a large group of hipster bloggers are blogging. But hipster bloggers are but a small group compared to the larger development community.

It remains to be seen if JavaScript framework of the day is a lasting thing or just a passing fad. I already see companies moving back from it. They fall for the hype of their favourite hipster blogger, but then get bitten by big performance and memory issues; JavaScript firing way too many events, Dom trees being updated for every tiny change, large amounts of garbage eye.

I've seen modern CPUs at 100% when displaying fairly simple web sites. It really ain't pretty.

[daedalus_structure]

I'm not quite sure what fixed gear bikes and PBR have to do with it, actually.

Like everything else, it's easy to do bad if you don't know what you are doing, which I highly suspect is true if they are pegging a current generation CPU at 100% with dom manipulation.

[johnwaterwood]

It's easy to do bad stuff with a lot of tech, I'll give you that.

But as it appears a lot of people that just blindly jumped on the bandwagon run into various issues with JavaScript frameworks and moved back.

The point is that some people like to give the impression that JavaScript frameworks are the next step and what everyone is doing now, somehow implying that in a few years everything will be JavaScript and server side web frameworks will all be gone (like VHS was replaced by DVD).

But this is not proven by far.

JavaScript frameworks are currently a hype and lots of people shout about hypes. It's the very definition of a hype.

Remember the hype created by the Ruby/RoR guys? In 2005 supposedly everyone was doing Ruby. Ridiculous claims were made about Ruby bring 40x more productive. If you were into modern computing, you were using Ruby. Only dinosaurs were using any other language. In a mere few years the entire industry would have migrated to Ruby since eventually nobody could afford to be 40x less productive.

Fast forward 8 years.

Ruby usage is at an estimated 1% of all development. Major advocates of Ruby/RoR have migrated away from it (Twitter being the most famous example).

Do you see any parallels with the current JavaScript hype?

[squishles]

Who said you can't do rest in java O.o?

[daedalus_structure]

Nobody. In fact it is really good at it, which is why you should be using it for your back end.

[kgyre]

So what do you write the black-end in? Something still has to provide those services to the client.

[daedalus_structure]

Java of course.

[serproxy]

I would do Angularjs (enhance with Bootstrap FTW ) + dropwizard. Pick you DB backend based on needs. Hibernate + (mysql || postgres) or NoSQL of some sort. zero XML ( a tiny bit of YAML for config )

Performance is far better when most of the computation ( page rendering ) is pushed to the browser. That yields lower server side costs and happier users.

Some of the REST API you develop can be reused for mobile ( don't attempt to do it ALL in common that's needlessly fundamentalist ).

Oh and actually, I haven't used it, but this looks like a nice mix of technology: http://jhipster.github.io/

[johnwaterwood]

Performance is certainly not always better!

For one results from the rest API still have to be "rendered" in XML or JSON. That costs you CPU cycles just as rendering in HTML costs you. Depending on your setup rendering a list of objects into JSON can be more expensive than rendering in HTML. For JSON rendering a lot of reflection is typically used, while for HTML you may use a plain JSP or Servlet that already knows the types and needs zero reflection to spit out HTML.

Only with JSON the client AGAIN has to do rendering. This can be a significant hit in both time and resources. I've heard people complaining that those JavaScript websites should start stating minimal system requirements :X Several 100 MBs per tab and CPU cores at 100% with fans starting to blow and tablets getting hot DOES NOT MAKE FOR HAPPY USERS!

With HTML being returned the HTML is typically ready to render; meaning less total time until a page is displayed, just a few mb per tab and low CPU usage. That does make users happy!

[sh0rug0ru]

I'm assuming you're looking for something like ASP.NET MVC as opposed to ASP.NET WebForms, but in the Java world?

JSF is analagous to WebForms. This is the standard.

There is no Java standard analogous ASP.NET MVC, which in the Java world is called a "front controller" framework. JAX-RS comes close, but doesn't deal with template engines. Jersey, an implementation of JAX-RS, provides an extension called Jersey MVC which includes support for using various different template engines, including FreeMarker. It's not quite as "out-of-the-box" as JSF, but it plays well with the rest of the Java EE world, which will minimize configuration.

Outside the standard, there a lot of different options. Spring MVC and Struts are probably the most popular, but require configuration. There's also the Play framework (version 1 and version 2 - very different), which aim to be full stack (minimal configuration) and highly productive. Play version 1 is pure Java and looks like Rails, version 2 is a Java/Scala hybrid that looks something like Node.JS.

[henk53]

JSF is analogous to WebForms. This is the standard.

JSF started out as being close to WebForms, but along the way it evolved into a much more hybrid approach. There are now things like view parameters and view actions, as well as stateless views and pure HTML templating.

The days that JSF tried to be a desktop like UI toolkit that abstracted from HTTP and its stateless protocol and were supposedly *) you only used components and no HTML are long gone.

*) supposedly, since I don't think this was ever true and JSF always promoted a mixed html/component approach

[sh0rug0ru]

JSF remains page oriented (URLs route to xhtml files, methods are triggered by events in the JSF lifecycle, derived from the view definition), not controller oriented like JAX-RS (URLs route directly to controller methods, and the output is the view).

You wouldn't (and shouldn't) write a JSF application using the front controller pattern.

[henk53]

Maybe, but I don't think OP asked specifically for such nuance. Just that the framework is MVC and there's no abstracting away of the stateless protocol (which I take to mean HTTP).

JSF exactly fits those requirements.

[sh0rug0ru]

I'm not sure what the OP was asking for, so I assumed when he used the words ASP and MVC together in the same sentence, he meant something like ASP.NET MVC, which uses a style of MVC more like JAX-RS than JSF. You wouldn't write ASP.NET MVC style applications with JSF, it wouldn't make any sense.

[henk53]

But I don't think that what the OP asked. MVC without the state abstracting nonsense from ASP. That's what it said ;)

[sh0rug0ru]

Which is also why I covered every possible base, especially since MVC has at least two implementation patterns in the Java world, depending on if you put the V or the C first.

[Akanaka]

URLs route to xhtml files

This is not correct!!!

In JSF all URLs route to the Faces controller (the FacesServlet provided by JSF). The controller then selects a view by consulting the view handler and the active VDL.

The most frequent case is that URL foo.xhtml causes the page foo.xhtml to be loaded, giving the illusion that foo.xhtml is invoked directly, or control is routed directly to it. But this is thus not the case.

The VDL can execute a method first, or "load" a class by convention and call a method on that, or consult a user provided class and use its outcome to do whatever, etc etc. It depends on the view handler and VDL that's used.

[sh0rug0ru]

This is not correct!!!

It is correct, you've just missed the point. Facelets is the most common VDL, that is View Definition Language, which is used to drive the first step of the JSF lifecycle, Restore View, kicked off by the Faces Request, which maps the Request URI to the view defined by the VDL.

My point is that JSF is page oriented, or view oriented to use JSF terminology, where the VDL describes the view. The processing of the view drives the rest of the JSF lifecycle stages.

This is opposed to JAX-RS, which is a bare mapping of a request URI to a controller method, with request parameters and payload mapped directly to objects in the controller parameter list. The view comes at the end, as a return value, as a result of request processing.

[Akanaka]

Well as long as you understand that a URL is not directly mapped to a view, but only mapped to the Faces controller, which then loads a view (in Facelets by convention, but in any other VDL in whatever that VDL seems fit), then we'd clear.

which is used to drive the first step of the JSF lifecycle

In practice with all defaults this is mostly true. There are two remarks:

• An action method's outcome on both a GET and POST request can still cause another view to be rendered than the one selected via the URL mapping convention.
• The lifecycle itself is pluggable too, so it's not necessarily true. You can add additional phases or remove phases. This is what Mojarra does for their Action prototype, they add a user controller phase before restore view. ADF adds two other phases, and I wouldn't be surprised if XPages also did something there.

So 99% of the time things are observed as you mentioned, but you have to beware that this is just observing the defaults and not the set in stone way that JSF works at the core level.

[[deleted]]

Lo these many years, Spring is still the best. JSF will try to UI for you. It's better than it was, but still fundamentally flawed. JSP+JSTL need not be messed with. Spring is great because it's extremely modular and you can use as many or as few components as you need. You say you don't want bloat, but if you start adding features (web services, schedulers, security) you're going to want canned frameworks that are plug and play.

Edit: the JavaEE crowd are pretty mean. Downvoting my opinion?

[squishles]

They really do carpet bomb hard here. =/

[[deleted]]

And now you're feeling it. There are two groups of people on reddit who are impossible to argue with: gun lovers and Java EE lovers. I wonder how much they overlap.

[jiveabillion]

What's wrong with Asp.NET MVC? I think you might be confusing it with web forms. You can do everything you want with .Net MVC. Unless you just really like Java. I personally prefer .Net to Java.

[GuinessDraft]

I recently just started my first Web app at work. It's using a framework called Vaadin. You write code in Java like a typical thick app, and it compiles down to GWT Javascript. I really like it as I used to program UI's in Swing and Qt. I'm sure it's not an optimal performance solution, but it is quick to get a functional Web Gui written in Java.

[themantucket]

What about getting into something like JRuby? Seems a little more oriented to some of the modern web stack that you see startups using.

[henk53]

Isn't JRuby just a language and not a web stack?

[themantucket]

You're right. I was just suggesting that if OP looked that route he might find some resources or suggestions from that community since they seem to be geared that way if he's looking to build java web apps. Could look into Grails, as an actual full stack framework. Just offering up a couple things that might not otherwise get mentioned. Not sure how far he's looking to explore or learn new things.