| >starting stopping J2EE servers is time consuming. 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. |