Web Interface Frameworks
•Als PPTX, PDF herunterladen•
0 gefällt mir•83 views
A history of web interface frameworks used at ENA.
Empfohlen
Weitere ähnliche Inhalte
Empfohlen
Empfohlen (20)
Web Interface Frameworks
Hinweis der Redaktion
- I was asked to give a talk about web interface frameworks. Unlike backend technology that is hidden from view, web frameworks appear to change rapidly as if driven by the whims of developers. While this is true to an extent, change is more a response to changes in the technology used to consume the web.
- Let me take you back to 2006. It was the year Twitter and Facebook launched and Google bought YouTube. I was living in Bath and driving a Mazda Bongo. I owned a cutting edge mobile phone, the Sony Ericsson K750i. It had a great camera, played music and I could check my email. However, its ability to view webpages was pitiful. Internet browsing was something I did at a desk.
- I worked as a Java developer at a software company. I still took any opportunity to work on Lotus Domino Web projects as I could be a lot more productive than if working on the massive, monolithic, model-driven Java projects full of EJBs.
- Unknown to me, on the other side of the country, work started on EMBL Bank Webin. The choice to base it on JavaServer Faces was sound. JSF had been around for two years and was a J2EE standard technology. JSF suited Java developers. It abstracted away unfamiliar web technologies such as HTML, CSS and JavaScript. It used the stateless HTTP protocol and maintained state on the server, generating the web pages for display in the browser. This was the norm for web applications at the time. Either you had your server do all the work and deliver HTML, CSS to the browser or you used a plugin like Flash based Adobe Flex or Java Applets to create richer browser applications.
- For a couple of years the AJAX technique had been emerging. Instead of storing state for each user on the server, AJAX applications tracked state in the browser. Rather than generating a new page on the server for each request, JavaScript in the browser would request only the data needed from the server via XML requests. The JavaScript would then modify the existing page dynamically in the browser to incorporate the new data.
- Google Mail in 2004 was an early example of this technique, followed by Google Maps in 2005. As the servers served the minimum data needed, instead of whole pages, they did a lot less work. As they were not storing state, sharing that state between servers was not an issue so there could be many servers. It was possible to support large numbers of users by scaling horizontally with small cheap servers rather than vertically scaling using large, expensive application servers. AJAX was a technique I had been using in my Lotus Domino applications, as unlike with Java technologies like JSF it was much more common to work with JavaScript.
- The problem was, at the time browser support for JavaScript varied greatly. Just because something worked perfectly in Internet Explorer did not mean it would work in Firefox. JavaScript was ok for scripting menus on web pages but it was not well suited for large applications, not least because it was difficult to test and painful to debug. Google wanted to create a tool that allowed their Java developers to write JavaScript web applications. This is where Google Web Toolkit came from. The aim was to abstract away the browser differences, hide away the JavaScript, HTML, and CSS like JSF and allow testing and debugging of code with existing Java tools. GWT cross-compiled Java code to JavaScript, creating a different version optimised for each web browser. This made it possible to have complex functionality in the browser without having to use Flash, Applets or struggle with JavaScript.
- Elsewhere, web developers were seeing the opportunity of writing browser applications with JavaScript as a first-class language but feeling the pain of writing complex code. A few months after GWT was released, JQuery, written by John Resig, came out. It too aimed to solve cross-browser compatibility problems of JavaScript but by taming JavaScript itself rather than abstracting it away. The JQuery JavaScript library provided tools for working with different browsers and AJAX from JavaScript.
- In 2007 the landscape changed. The iPhone was released. With its big screen, WiFi connectivity and Safari, browsing the internet from a phone became tolerable, albeit fiddly. The iPhone supported JavaScript but it did not support Applets or Flash. For a web application to work on an iPhone it had to be limited to HTML, CSS and JavaScript. In 2008 Android was released by Google, creating even more demand for mobile web browsing and apps. At the time I was using GWT to build a Rich Web Application for planning and monitoring WiFi router deployments on Google maps. There were few alternatives to GWT for that sort of application. Even though it was designed for the desktop I was amazed to see it on the screen of an iPhone for the first time. I then went on to apply what I learnt to other web applications.
- By 2010 the iPad had been released. With its large screen browsing the web was a pleasant experience. There was also a great demand for native apps and they got their data from web services. Google Chrome was available for desktop and mobile and a lot of work had gone into making its JavaScript engine fast. At that time GWT, which could produce applications that could run on a desktop, a phone or tablet seemed a very good bet while Adobe Flex and Applets fell by the wayside. Adobe donated Flex to the open source community in 2011.
- It was also in 2010 that work started on SRA Webin at ENA. GWT was chosen as the web technology. This again was a strong choice at the time. GWT was at version 2, the ecosystem was mature and there was an active community. The major browsers all supported a plugin that allowed developers to debug their Java code while running the JavaScript code in their browsers. This made debugging a relatively painless experience. However, GWT was still a set of tools not a full framework. It had no opinion or recommendations on how code should be structured and it did not have a pretty set of UI components. While third party projects tried to fill the gaps there was not much guidance for developers and it was easy to run into trouble with larger applications.
- In October 2010, Google released AngularJS. Unlike GWT it was a full framework with a model view controller implementation and was very prescriptive about how applications should be structured. Unlike JSF or GWT, AngularJS did not disconnect developers from HTML, CSS and JavaScript. JavaScript was now a first class language and AngularJS embraced RESTful web services. Debugging was possible through Google Chrome’s developer tools. It was possible to write significant browser-based applications in JavaScript. In the following years, Google’s focus moved away from GWT and to Dart, a language that cross-compiled to JavaScript, AngularJS and Android. JavaScript engines in browsers became highly optimised, REST services that could service both browser and mobile apps became widespread. HTML5 features removed the need for Flash. JavaScript as the language for web applications made more sense. In 2013 Google completely transferred control of GWT to the open source community and effectively stopped working on it as Adobe had done with Flex two years earlier.
- In 2014, we were still using GWT for SRA Webin. We were using an older version because our servers were stuck on Java 6. The application had become complex and development was painful. The browser plugins that enabled us to debug Java code when running the application in the browser were no longer supported and stopped working. We had to instead recompile Java to JavaScript after each change and on older machines this could take 20 minutes. The development experience was so frustrating I started learning Android in my spare time to make me feel that at least I was making progress somewhere. We got out of this rut though. We moved to version 2.6 of GWT, optimising the compilation, and got much needed new machines. GWT development became tolerable again.
- In 2015 I was asked to develop the Checklist Editor, a new project, in GWT. My approach was different from SRA Webin: I favoured plain Java so that I could test using JUnit and make the GWT UI a thin layer on top. I wrote a command line client before I wrote the GWT UI. This let me test I had the business logic working and forced me to make the UI light weight. I used the latest 2.7 version of GWT with Super Dev mode. This allowed me to debug the Java code code in the browser without needing the discontinued browser plugin. I applied architecture patterns I learnt from Android to structure my GWT code. I chose Bootstrap UI components to get round GWT’s lack of built in widgets. I found this a much easier way of working and was pleased with the results.
- In October last year, after no updates for two years, the community released GWT 2.8 with support for Java 8 and the latest browsers. For me it is still possible to productively write an effective web application in GWT. If I was to start a new GWT project today I would follow the approach I took for the Checklist Editor with a few changes: My UI code would be event driven, inspired by React. My server side would be robust REST service not GWT’s proprietary RPC mechanism. The REST API would encapsulate as much business logic as possible and state would be restricted to the client. By using RESTful services like this, I would make testing of the server side easier. I would also be making it reusable with different UI technologies. When the next UI technology comes along, which it will, the services will still work so have a much longer potential lifetime. Only the light-weight UI would need to be re-written.
- The world has moved on since 2010, so for someone starting a new project now, not considering alternatives to GWT would be a mistake. We are not Google. We don’t have the same problems as Google. We don’t have millions of users or have submitters on smartphones and tablets. We are affected by the decisions the likes of Google make as we share the same eco system. When Chrome dropped Java Applet support this affected our users. When Google stopped supporting GWT it affected our development. We can’t stay still even if we want to because the eco system will move forward regardless.
- Six months ago Angular 2 was finally released. Angular 2, or just Angular, is Google’s complete rewrite of AngularJS. Announced in 2014, it has been anticipated while a multitude of alternatives such as Facebook’s React have emerged and been adopted by developers. For me it is attractive as it echoes many of the concepts that I learnt in GWT and Android. It also has a level of documentation and community support that GWT could only have dreamed of. So is it a good idea to adopt Angular 2? Effectively I already have, or at least I have adopted that style of development. My architecture, my UI framework, my RESTful web services would be similar if I was writing with GWT 2.8 or if I was using Angular 2. The main difference would be that I would be using Java to write code instead of JavaScript. Actually I wouldn’t be using JavaScript, I would be using TypeScript, a version of JavaScript that supports static typing. Errors are picked up at compile time not runtime, one of the main advantages of using Java. TypesScript has moved a lot closer to Java. The code I write would be cross-compiled into optimised JavaScript. This all sounds very familiar.
- If I did choose to make a move to JavaScript I would not be alone. Last week the results of a StackOverflow survey of 64,000 developers came out: Three quarters of developers identified as web developers. For the fifth year JavaScript was the most popular programming language, with Java at number 3. AngularJS was by far the most used web framework, with React second and GWT not listed. TypeScript surprisingly topped the table of best paid technologies in the UK, with Java at number five.
- In the battle for dominance for web development JavaScript has won, for now. We are not going back to the JSF and EJBs of 2006. There were enough people willing to engage with HTML, CSS, JavaScript and make it work. Abstracting web technologies to let Java developers continue build front ends is no longer necessary. In fact, JavaScript has crept onto server-side development too, with Node.js currently the most popular server side framework. Web development is not going anywhere. JavaScript is not going anywhere soon. Angular looks a very sound option for the next couple years until the next big change makes it obsolete too. As frontend developers we will always need to keep an eye on the next promising framework to replace our aging one.