SUMMARY: Frameworks that help build the web apps of tomorrow must keep up with all powerful new technology there is on offer. At some point your application has to adapt, and that is never a painless process. You can avoid a total rewrite however if you respect the rate of change of web frameworks and don’t allow your code to become too tangled up with them.
I loosely borrowed the title for this blog from Families and how to survive them , a self-help book that explains why we keep falling in and out love, by psychiatrist Robin Skynner and funnyman John Cleese (himself three times divorced). Well, the start of a new year is always a fitting time to take stock of what’s new and what’s dead or dying. I have finally said goodbye to Google Web Toolkit because for the past several months I have developed something of a love affair with Angular 2/Typescript and a REST backend with SpringBoot and Kotlin. It’s a stack so bleeding edge it doesn’t even have an acronym — KoTS? No, scrap that, please! I could well imagine it to become my toolset of choice for the next couple of years, but don’t hold me to it. Web frameworks are the boy bands of software in terms of user loyalty, and I have switched favours before.
Who needs web frameworks anyway?
Remind me why we need web frameworks in the first place? Back in 1999 we didn’t have them. If you wanted to, say, display a comma-separated list of values on a web page, this is what you would write:
1#!/usr/bin/perl 2print "<html><body><table>"; 3open my $handle, '<', './data.txt'; 4chomp(my @lines = <$handle>); 5close $handle; 6foreach $line (@lines) 7{ 8 my @columns = split(';', $line); 9 print "<tr>"; 10 foreach $column (@columns){ 11 print "<td>".$column."</td>"; 12 } 13 print "</tr>"; 14} 15print "</table></body></html>";
Brilliant! No dependencies except for a Perl runtime, no compilation, no boiler plate. Just FTP your employees.cgi and data.txt to an executable Apache folder and you’re good to go. Copy/paste with minimal changes and you have the true amateur’s idea of software re-use. You’ll laugh, but the field of budding web development around the turn of the century was truly cowboy territory. Everybody was re-inventing the wheel, writing their own templating language to fill placeholders in a static HTML file from a perl hash. Move forward five years and suddenly you could do really cool stuff with CSS and Ajax. Sadly there was no standard to speak of. Well, there was, but no major browser really conformed and when IE8 did its best to be more compliant all the old sites rife with IE7 hacks broke. In short: cross-platform compatibility was a nightmare.
Compatibility the GWT way
Enter Google Web Toolkit (GWT) in 2006. GWT lets you write client-side code in type-safe Java, which is compiled (some would say transpiled) to JavaScript into a single minified download customised for each combination of browser vendor, version and language. Among other things it offered an RPC mechanism to create client and implement endpoints using a pair of related Java interfaces. The framework would take care of (de)serialisation. “Brilliant!” is what I thought in 2011, five years late to the party. GWT’s compatibility layer abstracted away most (though not all) browser quirks of the time. I have worked on rich clients (for clients that were even richer) with some sophisticated UI behaviour like drag-and-drop, cancellable file-uploads, double-clicking, you name it. It worked fine anywhere you ran it, provided your browser wasn’t too far behind.
But all this magic came at a cost. From the beginning GWT was notorious for its long compilation time. Multi-language sites could take more than an hour to build. The vital development mode – to give you the illusion that the browser is actually running Java – was overhauled more than once because it required a plugin that broke with every Firefox update. Nevertheless, I was so hooked on GWT that I made it my selling point for consultancy work and even registered the domain gwtdeveloper.nl. I let it expire. You can register it if you want. I have fallen out of love. Version 2.8 took well-nigh of two years after 2.7. If we’re lucky we may see a version three before I retire, but I have lost patience already.
I took some time to explain what made GWT so great in the beginning because the compelling reasons to adopt it then are no longer there. To be fair, they tackled many of the shortcomings of the earlier versions, but over the past ten years the world around GWT has also mended its ways: standard compliance and cross-platform compatibility is much, much better than it used to be. The appeal has gone while many of the old drawbacks are only mitigated at best. For myself I can see no benefit anymore in transpiled Java now that I have TypeScript and the excellent support for it in IntelliJ IDE. The GWT-RPC mechanism is elegant, but it does create a dependency on GWT server-side, whereas a REST endpoint is fully ignorant of what’s running client-side. JSON serialisation is handled pretty well by Angular, it’s as simple as saying @RestController in Spring, and it makes your server backend much more re-usable for other clients.
Two roads to irrelevance
There are many reasons why perfectly fine (web) frameworks can nevertheless become irrelevant. I’ll concentrate on two. One is that the world around it has developed a better or more efficient way of doing things. Web application development has always been a very dynamic playing field. Users want rich, responsive web applications that run on multiple client platforms (PC, tablet, mobile) and the tools desperately try to catch up. GWT made great strides around 2012, but from a user’s perspective development seems stagnated for the last years. Sure, supporting Java 8 syntax in the JavaScript compiler must have been a real bear, because it took ages, but in the meantime TypeScript came to the scene with superior lambda syntax. Tough luck.
Paradigm changes are a second and more fundamental reason why some software is ready for the museum. In the early days the web was a bunch of static hyperlinked pages, basically HTML. Then came linked images, user forms and JavaScript. Dynamic manipulation of the DOM and Ajax enabled smooth single page applications. Now we want multiple versions optimised for PC/tablet, mobile and smartwatch. Early web frameworks were toolsets for doing things the old way, i.e. generating an html stream server side using some template or widget mechanism. Even in 1999 you could argue that it wasn’t the best way to build a responsive web app. It just happened to be the only way to do it. That worked fine for a long time, but here’s the dreaded car analogy: more energy-efficient petrol engines are irrelevant once we have a viable electric alternative. Trying to improve something that has become outdated or inferior is just silly.
Both forces are at play in web development frameworks: we keep getting new and better technologies and languages (HTML5, CSS3, Websockets, TypeScript) to build stuff we can’t really build comfotably unless the tools to support them adapt, sometimes radically. I sympathise with those who lament that Angular 2 is actually a new framework rather than a version upgrade. I also have time invested in Angular 1, but I found learning Angular 2 well worth the effort.
Well, it seemed like a good idea at the time
Here’s what can happen if you bet on the wrong horse. I can recommend Scott Rosenberg’s book Dreaming in Code about the brave effort by Mitch Kapor and his team to build an Open Source PIM (anyone remember that acronym?) called Chandler set to kill Microsoft Outlook. Spoiler: it didn’t. Kapor sank millions of his personal capital (he invented Lotus 1-2-3) into the project and learned an expensive lesson in humility. It’s tempting to get smug about the team’s poor decisions, but choosing a server-less peer-to-peer architecture and a desktop client (one you have to download, double-click and install) was probably the most ill-fated one. It seemed a good idea at the time. It probably was a good idea when they started, but writing the ultimate Outlook killer takes time and by the time you’re finished the world is a different place.
Is there a lesson to be learned from all this? Only that resistance to change is rather futile and (economically) unwise. Web frameworks adapt to the new way of doing things and if you want to grow your software with it you must be prepared to learn and adopt to the new ways. This is not a cheap or effortless process. Switching web frameworks in an existing code base can mean anything from a hefty refactoring to a complete rewrite of your application, not to mention the learning curve for the team and the powers of persuasion required. Converting a code base is one thing, converting the more conservative forces in your team is another. That’s why there’s still disgruntled hordes tinkering with Struts and JSP monoliths. You’re not going to attract the greatest talent is that what you can offer them. I once worked on a major JSP ‘enterprisey’ application whose pages were basically dressed-up editing forms for a corresponding Oracle table. The entire architecture of the application was dictated by the Oracle and JSP way of doing things, making code re-use for different clients (e.g. mobile) impossible. Still, there really is one thing worse than having such an architecture, and that is having an ad-hoc, home-baked, non-standard way of doing web apps, like in my Perl example.
Everything changes in web land but it’s safe to assume that HTML, CSS and JavaScript will be with us for a while. Likewise JSON, REST and Spring. Grunt, gulp, yeoman, yarn and any other flavour of gluten-free hipster build frameworks? Don’t hold your breath. ‘How easy will it be to migrate this to […]’ is a very prudent question you should ask yourself regularly when evaluating options. The solution – as you will have guessed – is in minimising and centralising the amount of code that touches your framework library. Be prepared to make liberal use of the Adapter/Facade patterns and you’ll thank yourself later. I wish you happy learning for 2017.
Was this post helpful?
More articles
fromJasper Sprengers
15.11.2017 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Jasper Sprengers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.