Karsten Lehmann 21 September 2014 21:50:48In a recent comment in this blog, Andrew Magerman asked what frameworks I use to build web applications and whether we have looked into Angular. Since the answer got too long for a simple comment and might be interesting for others, I created this blog article.
I am using my own regexp based templating system, which simply fills some placeholders in static HTML and JS files and sends them to the browser, e.g. to compute URLs, to insert translated phrases and include content of other template files. I don't need much flexibility for this template system, because all dynamic stuff is created in the browser anyway.
Data is provided via custom REST services implemented in Java that offer CRUD operations. In many cases, the server side application code uses framework classes from OSGi plugins that build a common layer shared between multiple web applications.
For the frontend, I use Bootstrap to build responsive user interfaces that work on phones, tables and desktop browsers. I use jQuery, lots of helper projects like bootstrap datepicker and timepicker, select2 for flexible comboboxes, velocity.js for animations, Asynquence to work with callbacks and other libraries that I tweeted about in the past.
To wire them together I use require.js, which gives me a clean dependency resolution.
React based UI rendering
For more and more UI components, I use React for the rendering and their flux application architecture.
I especially like their approach to reduce DOM changes by comparing old and new in a virtual DOM tree in memory when data changes.
Another advantage of React.JS is that the initial UI code can be precomputed on the server side to improve SEO ranking (see this article).
Normally, this is done in code running in a Node.JS server.
We haven't used Angular in real-life projects yet. Looking at the documentation, it feels as if they over-standardized web application development a bit, making it more difficult than necessary to get started.
What concerns me is that their templating system does not seem to optimize DOM operations as good as React does. In the browser, it's all about responsiveness and performance.
What I don't use
Personally I prefer not to use JSF components or similar concepts for the web UI. I don't like to depend on a server state and don't like to have too much communication between frontend and backend.
Instead I like to have most of the UI code in the browser so that the app is responsive even with bad network coverage. In addition, I can optimize DOM rendering and have more ways to play with animations and transitions.
Communication with the server side is done through REST APIs that can also be reused to test functionality, automate tasks or for automatic data imports/updates.
You may have noticed that not much of my way to develop web applications requires a Domino server.
Having Domino on the server is a great thing, as it includes many services in one consistent platform, like the document database, fulltext search, directory services, replication and a close integration of application code and the mail server.
But there's more than one way to skin a cat. We have prototypes in the lab that don't have any Domino dependencies.
Since we like document databases combined with replication, we have been playing with the CouchDB eco system for some time:
the Apache CouchDB project that is currently merged with the Cloudant database and the rcouch project as well as its mobile version Couchbase Lite and PouchDB in the browser.
Combined with an OSGi based server platform, that looks like a powerful and extensible app dev environment.
- Comments