Java EE 8 without MVC?
After almost one year of silence Oracle presented an update to the Java EE 8 roadmap at JavaOne: Java EE 8 by the end of 2017 and EE 9 one year later. As far as I know they didn’t explain why they stopped their work for so long or why they left the community in the dark about that. OK, but at least some progress now.
The new roadmap introduces two new JSRs (Health Checking and Configuration) and also proposes to drop Management 2.0, JMS 2.1 and MVC 1.0.
Especially the plan to drop MVC triggered controversial discussions. The statement behind this decision is that MVC does not match with Oracle’s new cloud strategy. Honestly I’ve no idea why “the cloud” could be an argument against a RESTful web application framework but luckily Oracle explains this in more detail in the new Java EE Community Survey:
When we first proposed Java EE 8, we got feedback that an action based web UI MVC framework standard would be a good addition to Java EE. At this point it seems that most new applications are using JavaScript based UI frameworks. We’re now questioning whether it is still important to complete the MVC API (JSR 371).
How important is MVC API for the next generation of cloud and microservices applications?
So: times have changed — Single Page Apps ftw!
I think Oracle got it wrong and the answer is: Yes! It’s very important to complete a framework that encourages web applications following some basic web principles like them from roca-style.org. You don’t believe that unusable browser controls are still a thing? Go back to the survey and try to copy text or use the back button. Good luck!
Single Page Apps may be a good fit for your project. I’m using AngularJS in many of my current projects too. The motivation is mostly the same like years ago for JSF: We’re quite productive and it’s easy to find developers. But I’m also aware that sometimes this is a poor compromise for the user:
SPAs make high demands on their clients. This may be ok if your application runs only inside your companies network and you know your clients. In the web this is typically not the case. Years ago we struggled with layout problems if we used a feature which wasn’t supported by all browsers (or most of the time it wasn’t supported by one browser). Today this is different. A non supported JS feature may break the whole client and your user gets a blank page without fallback. Of course also the distribution of new browser features is much faster than years ago but I can guarantee that not all of your users will be on your level. Progressive enhancement may be a good alternative if you‘re tired polyfilling old browsers. Just send semantic HTML to your client and enhance it with CSS and JavaScript as much as you want. The basic functionality will always work.
SEO has also been a trouble zone for SPAs but this seems to be changed as Google announced that they execute JavaScript a year ago. But Google is not the only non-browser client of your application. More and more sites and chat clients display a preview of your site if you post a link but not all of them will execute JavaScript. {{ title }} — {{ description }} is maybe not what your users want to see.
Performance is the next discipline where SPAs are no model pupil. When I finished performance tuning of my first AngularJS application I was quite surprised. I did everything what I’ve learned before like concatenation and minification of styles and scripts but it didn’t improve anything. The user had to wait a few seconds till the browser finished to download and parse a very big JavaScript file. Reminded me a little of waiting for an ancient version of Weblogic to boot. There are a lot of studies about performance and success of websites, the last one I heard of states: “53% of mobile site visits are abandoned if pages take longer than 3 seconds to load”. 3 Seconds is something which is hard to achieve with a Single Page App. And it’s almost impossible if your users have a bad mobile connection.
Many JS frameworks like Ember.js and React give you the opportunity to also render HTML on the server. Google’s Application Shell Architecture proposes to render at least the “shell” on the server. This is not a new trend. Twitter migrated back to server side rendering 2012 because “time to first tweet” really matters. If Oracle thinks that times have changed and the trend goes to client side framework they’re late again and may miss the trend back to the server if they stop MVC now. And btw: Wouldn’t it be great if Java EE would provide an answer how to build applications which render on server and client? There are already people integrating React with MVC!
If you haven’t filled out the community survey yet please take a few minutes of your time. The survey will close on Oct 21. It’s really important that you give feedback and the future of Java EE is driven by the community.
