JSF is the slowest way to do web development for rich client UI: starting stopping J2EE servers is time consuming. HTML templating is difficult; you can't see what you screen looks like until you serve the page from your J2EE server .Also JSF is an unnecessary abstraction over HTML : it is much easier to maintain state on client itself using any of Javascript libraries like React or Backbone or others. You are much better off using REST servlets or REST Spring MVC with your javascript. JSF impedes the growth of features or functionality on a page: as you add more widgets to you page like JQuery plugins , you will be suprised by the amount of backend code you will have to write. Ultimately ,you will eventually resort to hacks and you page state and you JSF state for the page will deverge. Sadly you wont discover this mess until you are waist deep in this pile of muck.
JPA is pretty awesome ; however I have learnt over the years that you need to fine tune your queries using explainplan rather that relying on generated queries; define the views on the db itself and load them with JPA; this way the others frameworks or related application ,like a ASP application or a python web application or reportng application, can also leverage the same data and view.
I can sign manishsharan's approach: just use a REST server and a SPA framework. It makes frontend problems leaking in your backend much less likely to happen (another problem some developers had with JSF at my last job). You are forced to separate UI and backend which is a problem that's not exclusive to JSF. It's also easier to make features of your webapp available as an app where it makes sense.
BUT before i start to sound too much like a fan boy, where jsf fails is when you need to anything off the jsf path. Then you are looking at implementing custom components or tacking on the entire client side js ecosystem.
So, jsf may have a place for rapid implementation if your devs aren't proficient with client side ui imo, but thats about the only time its appropriate, again imo.
The interview mentions OmniFaces and PrimeFaces. These are not frameworks on top of JSF.
PrimeFaces is a component library. The entire purpose of JSF was to make such libraries possible. It introduced a component model with exactly the intend that a marketplace of components would appear.
This indeed happened. There's PrimeFaces, RichFaces, IceFaces, Trinidad, and a few others. They don't "fix problems" in JSF, but are what JSF was created to provide.
OmniFaces is a little different. It's a utility library. It does fixes small inconveniences in the JSF API, but it too is not a framework and makes use of the very extension points that JSF explicitly has provided.
Compare this to Eclipse. It's weird to say that JDT is a framework on top of Eclipse, since Eclipse was specifically made to host plug-ins.
Starting and stopping j2ee servers indeed takes a long time. But so does booting Windows 9 on an old 386.
Why do you bring up J2EE? The article is about Java EE, which is really, really fast in starting/stopping. On my 3 year old desktop (Ubuntu 14.10, 3.4Ghz i7, 16GB RAM, Samsung 830 SSD), JBoss starts in exactly 1 second. Liberty takes 1.5 orso, GlassFish takes between 2 and 3 seconds.
That's not a LONG time, IFF you need to restart.
For typical JSF you don't need to restart at all. You make a change on the page and reload the browser. That's it.
With a standard JVM you can also make changes inside Java code, as long as those changes are inside a method. The IDE will hot deploy only the changed code and the JVM will hot reload it. If you want to structurally modify classes (add/remove methods, add new base class) then you can still hot reload them, but you need to install JRebel. This has little to do with JSF, and more with Java in general.
>you can't see what you screen looks like until you serve the page from your J2EE server
Not true. JSF lets you create pages using normal HTML, which can be previewed from their source.
>Also JSF is an unnecessary abstraction over HTML : it is much easier to maintain state on client itself using any of Javascript libraries like React or Backbone or others.
What's easier is perhaps personal, but I don't think the abstraction is unnecessary. First of all when using normal HTML to create pages there's not much abstraction in the first place, it's normal HTML. Then the advantage is that you can VERY EASILY bind input/output to the server. Client-to-server data binding is JSF's strong point.
And it's not just easy, you also get validation thrown in there for very little cost and JSF is aware of what it has rendered when processing data that's being send back. This allows it to mitigate certain attack vectors, like the mass attribute assignment vulnerability in RoR.
>you will be suprised by the amount of backend code you will have to write.
Funny, how my backing beans are always really small and simple, despite the pages being of arbitrary complexity.
>Ultimately ,you will eventually resort to hacks and you page state and you JSF state for the page will deverge.
Rarely an issue if you half know what you're doing. Client side JSF can make all the changes it wants, and when it's time to update to the server you send that data to the server. Where's the problem?
In every client-server architecture there are sync issues to be aware of. With a js client and JAX-RS the server can also be out of sync if other pages or other clients made changes. This is not unique to JSF.
Would definitely like to see why something like Dropwizard, Vert.x or even Play 1 wasn't considered.
The fact is that both invoke memories of old times where they were very heavyweight and problematic technologies.
EJB was a total disaster, where you needed to implement 3 interfaces and inherit from a framework provided base class, compile your code with a special "enhancing" tool and run yet another tool to generate something called stubs and skeletons, just to do hello world.
Modern EJB on the other hand is a POJO with a single annotation:
@Stateless
public class Bean {
// do something
}
In modern Java EE there's no reason whatsoever to avoid EJB.
There's a similar story with JSF. The first versions (1.x) were mostly POST focused, had heavy session space requirements, and components were hard to create.
In modern JSF 2.x, there's first class support for using GET, and the PRG pattern is at the heart of interactions that are logically POST. Session requiremebts are largely minimized by use of a partial state saving (only changes to state are saved) and a stateless mode (nothing is saved). You can use plain html to author pages with a single extra namespaced attribute to mark it as a component to JSF.
Again a night and day difference and no need to avoid it anymore.
Then JSF has a number of very cool extensions available such as PrimeFaces (beautiful visual components) and OmniFaces (Swiss army knife like Guave is for plain Java)
Now, my biggest problem with the stack, and the reason I do not use it anymore, is Java itself. A switch to Scala makes a lot of the Java boilerplate go away, and even Java 8 doesn't get close. Now, I find all the major Scala web libraries to be lacking, in one form or another. Play's second compilation feels clumsy. Spray's freedom of routing leads to very ugly code: Just look at their own large examples. So what I am currently doing is using a homebrew routing on top of Spray, which also gives me some documentation for free: Pretty useful when you have hundreds of services in hundreds of servers.
It's a pity that Java itself moves so slowly, and is so reluctant from adding key features, like pattern matching, because the rest of the tooling is pretty good.
I don't see much reason to use it, either. The only exception is for distributed transactions, where session beans serve as nice abstractions as entry points and managers for the transactions.
There are probably more java EE jobs out there than ruby ones. (It doesn't say anything really, except the fact that some places don't laugh at you if you suggest Java EE, some places would laugh at you if you suggest anything else)
I've spent at least 15 years in enterprise companies and most new projects I've seen have been Scala/Clojure/Java 8 style in microservices form. Less so the monolithic WAR style apps.
Not dismissing the choice at all. Would just like to hear more about why they are bucking the popular trend.
You'd be surprised.
I don't even know where you got that idea. BOTH are widely deployed and used in enterprise.
(Dropwizard uses JAX-RS by the way if I'm not mistaken)
Now with Java 8, Java EE is quite a powerful and productive framework, and the performance is pretty predictably just awesome.
In Java EE 8 such a new MVC framework is indeed coming. From the same startup the article uses as an example: https://mvc.zeef.com/manfred.riem
That page is from the MVC 1.0 spec lead (Manfred Riem). It's going to be strongly based on JAX-RS and mimicking how Spring MVC and Jersey MVC now works.
I think it leads to the UI framework (e.g. JSF in the past or this new MVC spec) "winning" and getting adopted by teams who, if they had to evaluate several competing non-blessed frameworks, would pick something better/easier/more modern, but instead go with the JSR-backed option.
Although perhaps I'm just being pessimistic. JSRs can probably be a good thing; as a programmer in the JVM ecosystem, I've just never considered "it's a JSR" as a brand of quality/something that should affect my choice, and if anything it's the opposite.
(My pessimism aside, if they're basing the spec on existing good ideas, like JPA did for Hibernate, and JSR-310 did for Joda time, that is at least a smart approach.)
But the static typing is really good ,ofcourse the language too .Maybe I should I've tried Jersey .
I counted LISP out because unless you're using Clojure, I know for sure you're not going to be able to beat anything else for web-app development. LISP for web-app probably works in the 90's for PG but we're in 2015 where libraries, frameworks, and tools for these other languages are just far too advanced and more productive than writing macros... sorry mate.
Anyway, back to Java over Ruby/Python.
Take a few examples:
At the Microservice area, Java seems to shine over other languages/platforms. JAX-RS feels more complete than Sinatra or whatever Django plugins that the Python community use. See a quick example of JAX-RS vs Sinatra somewhere in this blog post: (http://www.appneta.com/blog/microservice-service-oriented-ar...)
Maven can be huge and underwhelming (and ugly once in a while) but it's definitely more powerful than gems+bundler+rake and whatever Python adopts these days. Maven has been around for a while so most Java DEVs don't have to pick up tools as Python DEVs have to do quite often. But again, there are trade-offs: Maven XML is definitely uglier than Bundler or requirements.txt or package.json.
Let me ask one thing: in platform other than Java, do you use declarative transaction? My guess is "No". Which means you have to know when to open and close a transaction (and potentially join an existing one if the library isn't smart enough). Java Spring/EJB provides annotation based transaction.
I'm not suggesting that Java is better than other languages, but there are advantages of choosing Java.
And, of course, at least they won't have do a rewrite when it becomes apparent that they have to scale big time.
Our current project uses Spring MVC for the backend, exposing REST services, and GWT for the frontend, with Resty for marshalling data structures back and forth. It works really well.
GWT is nice, but I remember a lot of frustration came from buggy dev modes and compilation times.
Granted, the non-JVM debugging experience is not nearly as magical as it was before, but I believe there is some work afoot to merge SDBG (source map-based debugging in Eclipse) + the GWT plugin. Still WIP.
I kind of enjoyed debugging in the IDE with the old dev mode, but I agree it was kind of quirky and slow.
Yes, JEE/Java is bad but please, there is no perfect framework/language. Ruby/Python/NodeJS whatever is awesome, but it does not mean that it is perfect langauge either.
Now JEE 7 is awesome enough that you should stop mention J2EE.
Also, Java maintenance best backward comparability that I ever know. Anyone want to discuss Python 2 vs Python 3 and Ruby 1.8 vs Ruby 2?
To whom does Geronimo sell consulting hours?
The design-by-committee hasn't been the case for at least 10 years. J2EE 1.4 was the last version largely developed that way. The last released version (EE 7) and the current one (EE 8) sees a lot of community contributions.
People from the community create JIRA issues, send contributions, even implement entire features (see the work for JSF 2.3 and MVC 1.0).
If that's design-by-committee then everything is design-by-committee.
> that lack of external perfection does not make JEE usable or worthwhile.
So tell me, which framework does not lack of external perfection and make it usable or worthwhile.
Even after Rails, the Java ecosystem is less "everything out of the box" and more "build your own stack". There are some exceptions, e.g. Grails and Play. Although both of those have migration modules:
https://www.playframework.com/modules/migrate-1.3.2/home
https://grails.org/plugin/database-migration
(First hits from Google, so apologies if those aren't the latest/best results.)
And, even then, I think both Grails/Play also try to be backend-agnostic, e.g. the migrations being plugins instead of first-class/backed in, like Rails which assumes "yeah, you'll basically always use a relational db".
Also, re migrations, a shameless plug for my ORM that relies on migrations+the database schema to codegen the rest of the boilerplate: http://joist.ws/.
There's Flyway and Liquibase. Having that said, once you have branches, triggers, set up subpartitions and have PL/SQL blocks that mix DDL and DML things aren't easy anymore.
So there are some options available.
I for instance wanted to build a webapp with the StanfordNLP .
To Google J2EE sucks is not that difficult. My favourite quote from Bell Labs folks - "whole encyclopedia could be written about what is wrong with J2EE". Rebranding doesn't matter - it is the same crappy mess of piles of unnecessary layes of ugly, redundant abstractions.
Don't be hypocrites. It sucks.
While I'm happy for him, I dont think it makes a good case JEE as a "startup's secret weapon" (SSW).
By hypothetical comparison, if someone used 6 major tool chains for the last $DOUBLE_DIGIT_NUMBER years, and by comparison says one particular tool chain is an SSW, then I'm much more inclined to value the recommendation.
That said, it DOES mean that they have been happy with Java EE and have been so happy that they choose it again for their latest startup.
Contrast this with a typical startup where engineers always seem to hate whatever they used before and are like children in a candy shop for having the opportunity to use whatever we think is cool here.
Sure. I'm also happy for them, and I acknowledge JEE's massive installed-base and performance.
Just the "startup secret weapon" claim/title I thought was unfounded.
Ignoring the business logic, a RESTful API can be built to run on a Java EE application server in about 10 lines of code. And it will run on any Java EE 6-7 compliant server implementation (as a single JAX-RS application ... you'll need Java EE 7 for multiple JAX-RS applications per context).
EDIT:
I also should have pointed out that the "XML Hell" that was required to configure applications and almost every managed object in J2EE <= 4 has been eliminated. When the default behavior isn't quite what you want, meta-programming can be accomplished with an annotation in the code. The few remaining XML files can often be left empty - they're simply markers that activate features of the server (CDI bean scanning, Java Server Faces, etc).
I have seen in /r/java and Reddit and elsewhere people eschew even for newbies the use of Spring Boot, Ninja, Dropwizard in company. Some like you say Java EE is very friendly and I can write a full-featured REST service in like a dozen or so lines of Java. Seeing as I wrote small pieces of homework "employee ID insertion into memory" classes in like 100-200 lines, can you show me said examples? Hyperbole or not, I would love to see good articles about building REST services and other stuff in pure Java EE and/or JAX-RS style explaining how a Java newbie can do this stuff.
I think other novates would greatly appreciate. The expanse of Java web libraries is so vast even showing the minimalist modern style I am jealous of in your post would be a huge benefit to me.
UPDATE: Oh Jesus Christ! Now I remember why the name Zeef seemed familiar. You make that one of the few tutorial sites I found. Now, I will go crawl under the HN couch while onlookers stare and surpress chuckles. Always read the articles, dammit! Or meet me under the couch, rather.
Modern Java EE let's you start about as fast as rails, especially when starting from a good Maven archetype. The code is immensely simplified. I got a backend service with JAX-RS and CDI running in literally no time!
Also consider APIs/Baas: Backendless.com, Kinvery, App42, etc. http://baas.apievangelist.com. DIY REST is purely optional, for companies w/ poor CTO/CFO. PHP, JSP, ASP, Rails, Django is in same boat, server side rendering of UI is past prime, we now need stunning UI, ex: datatables.net, Admin LTE, etc.
Framework today is UI Kit, BootStrap, Foundation, etc. That is a framework. Alternative to that is PhoneGap, Swift - and for Java, there is hope, in Android.
I looked at zeef.com and it is an interesting idea, but I tried searching for a few broad topics that I am an expert in and found the results so-so. zeef.com needs a larger number of human experts contributing.
"So our strategy has been to reduce the number of relations between entities to what is strictly necessary, and occasionally to use JPA DTOs when a subset of data is needed for a rather complex entity. Such DTOs are populated using the constructor selector syntax in JPQL queries and JPA is generally smart enough to generate far more optimal queries then."
I have been using this "pattern" a lot lately, its great. looks something like this:
SELECT NEW mypackage.Pojo( e.id, oe.name ) FROM MyEntity e JOIN e.otherEntity oe WHERE e.someProperty = :parameter1
Its also possible to place these in external files, working around Javas inability to have multi line strings after all these years.