//log//

After being into software development now for almost 20 years, counting in student days, these days I have to admit I spent most of this time, and especially most of my “productive” work on the server side using Perl and Java, with Python and shell scripting always being around as tooling things but never as real first-choice languages. Through these years, also my perceptions of architecture, technology and, actually, using server-sided Java have changed in many ways – from “web-only” applications to more complex structures running inside Java EE application servers to more lightweight structures running as standalone applications embedding HTTP servers or modules listening on messaging systems such as ActiveMQ or XMPP. Another change that happened all along the way is that JavaScript made its way from something everyone loved to hate to something everyone at least seems to want to use for day-to-day work. And while, after taking a few deep dives, in some fields I surely do understand this, in others I don’t at all…

For quite a while I’ve been a very avid opponent of the approach to build things such as single-page applications, felt closer to the RESTful or resource-oriented thinking and considered things such as routing, linking between “things”, … to be something that should go to a backend rather than to an in-browser application. By now however, considering most (all?) browsers essentially are not just document viewers / renderers anymore but runtime environments capable of housing and running complex interactive applications, SPA surely makes sense – as the “client” part of the applications that interacts with a RESTful API on some backend server behind. No matter whether people actually do “real” REST (including HATEOAS and providing different media types for resources) or just a subset (HTTP GET/POST + JSON) – things suddenly make sense in order to build meaningful client/server applications, and given the client (=browser) world, this approach on the long run might be way more meaningful and usable than, in example, the approach very common in the Java world to hide all the client specifics behind a mostly server-sided framework such as GWT/Vaadin or JSF.

But: At this point, of course tools and frameworks are needed to get productive on the client side, to get things to really work really fast. And: If there’s one real benefit about JSF or GWT, then that these things are so tightly integrated into Java runtime and development time tooling that you very effectively can build applications without ever having to bother knowing there’s a browser and network in between – business applications can be built using the same model and the same logic straight through all layers from persistence to UI, without having to deal with different language or different programming aproaches. Yes, this model has quite some limitations, but it also has some benefits. So, moving from a pure Java environment to an environment exposing REST (or even WebSocket) endpoints and running presentation / client logic in the browser should come up with an environment that is at least not much worse than what has been left behind.

And, about that, I pretty much stumbled rather early on this way – in trying to figure out how and where to get started. Simply put: Up to know I was pretty safe in my belief that Java is the #1 language when it comes to providing redundant, just partially usable frameworks to add web interfaces to your server sided application. But by now I am sure Java isn’t anymore; JavaScript does soundly beat Java at least in this field. Just looking around for a few hours, at some point I stopped counting: ember.js. angular.js. barebone.js. can.js. knockout.js. … …

Yes. At the very least at this point I am literally knocked out. All of these frameworks seem more or less “mature” at first sight, though in some cases it’s pretty hard to see who’s behind these, how they are maintained and whether or not they actually are still active. Most of these frameworks provide pretty decently styled post-Web 2.0 web pages. All of these frameworks in some way or the other claim to “ease your development” and “boost productivity” by providing the developer with a “lightweight” or “simple” framework to focus on what’s essential rather than having to deal with the framework itself or writing unnecessary boilerplate code.

Sounds all good, doesn’t it? Yes it does. But at this point, I got almost lost here simply because it seems impossible to make a smart decision. All frameworks seem to do more or less the same, all seem to have fields in which they shine and fields in which others do better. All, as far as it goes, seem to not really provide answers to some of the issues I definitely see in JavaScript, coming from a Java world (providing a sane, stable management for dependencies or transitive dependencies, in example, that goes beyond just saying “add this and this javascript file to your application, oh, and that one too” – which is, by the way, not something specifically solved in Java; virtually any other language seems to have concepts for that by now). And neither of these seem to provide any sort of IDE or tooling integration that is somehow on par with what one expects coming from a Java or maybe a .NET/C# world.

So, I see it’s learning curves all over – which is both okay and a bit frustrating as this means learning curve at a point where it’s not just about learning how to get productive but actually learning how to make an educated decision. It’s a bit frustrating, too, because essentially it’s hard (impossible?) to say which of these frameworks still will be around five or three or just two years from now. And at some point I surely wonder why on earth the world needs several dozens of frameworks doing virtually the same (and still leaving things to be desired), rather than people would join forces on focus one or two frameworks to eliminate all the shortcomings to be found these days and be flexible enough to cater to different users needs. At the moment, I feel in a not too good way reminded of my study days: Back then, it seemed each CS student who wanted to do more than just the given programming class assignments actually started building either an X11 window manager or a barebone mail client – with the result of the world being flooded with inferior window managers and MUAs no one would actually need or use. Few years later, it seemed all the same if you replace “window manager” with “CMS” or “mail client” with “weblog engine”. Now I see similarities looking at JavaScript libraries…

But I digress, and I guess ranting about how things are won’t make it better. There’s a bunch of web sites and articles out there helping one to get started at least comparing various frameworks and understanding what they are (not) good at, two of them are linked below. And… I haven’t really made a decision where to start, so far. Reading through some of the comparisons, it seems backbone.js, maybe enhanced by marionette.js, might be closest to what I want to start over. But even though it’s not at all a critical decision (as mainly this is something I want to play with, not something immediately required for productive work), maybe it’s just go and try, and maybe it’s also another way to get back to NetBeans as an IDE a bit more again, after mostly using Eclipse for productive work and knowing that NetBeans has excellent JavaScript/HTML5 support. So at least it’s an adventure to start with… Anyway: What frameworks are you using for your productive or semi-productive work, and what are the reasons why you chose this?

Links:

• Are single page apps bad?– interesting read on the ‘Single Page App vs. RESTful applications’ dispute, especially focussed on ROCA.
• JavaScript framework comparison on airpair.com
• JavaScript framework comparison, a bit more extensive yet a bit older
• JavaScript with RESTful Java backend (vidcast by Geertjan Wielenga)

Filed under: