Building web apps means that you need a front end that the users will interact with. With Domino the answer was XPages ( or for the hardcore old school developers you could use forms and views and pages with passthru html ) but when moving to a new development stack XPages is no longer an option so what can you use…
There are two schools of thought around fronted development. There is the client side rendering group and then there is the server-side rendering group. For client side rendering the application is mostly written in JavaScript which, when running in the browser client, will manage what is shown of screen and manage the data transfer from the front end to the backend via REST data calls. Server side rendering is very similar to how XPages worked with the server building the webpage from whatever templating system you are using and then sending that to the browser to display.
So before you decide on the front end technology you do need to decide on whether you want to do server-side rendering or client side rendering. Server side rendering can result in more security for your data as the backend rest calls are not exposed to the client in any way, the client only receives the data after it has been retrieved and processed by the server, however for a very busy application your server needs to be powerful enough to do all that processing so it can return the rendered ui to the user in a timely fashion.
For client side rendering all the processing is done by the client browser application. It just gets a raw stream of data from a REST endpoint and then renders that for display. The server no longer has to spend processor time on rendering of UI and data, however this does mean that the client needs to know about these REST endpoints so they have to be exposed to the outside world so there are security considerations to be made.
On the client rendering side you will find things like pure JavaScript, Angular, React, Polymer and a whole host of other different frameworks. One trap that you could fall in to is jumping from one framework to another because everybody else seems to be switching from React to Vue so you should be doing it also. This can cause delays in your project as your front end developers learn new technology so it is something to keep on your radar.
Server side rendering also has a number of frameworks to select from but they can be quickly narrowed down depending on what you selected as your main backend, if you are using .Net for the backend then you are probably going to select ASP.net for the UI. If you picked Java then you might use JSP or Apache Velocity, Apache FreeMarker, Thymeleaf, JTwig, to name just a small few. Other languages have their own templating engines that they use.
For our future development we decided on using Server Side Rendering with the Thymeleaf templating engine. As we are using Spring Boot for the backend Thymeleaf makes an excellent choice. There is a Thymeleaf starter project for Spring Boot which will pull in all the dependencies you need automatically and Thymeleaf itself has some specific Spring integrations also.
If you, however, are heading down the Spring Boot + Angular path then make sure you also check out JHipster. This is a code generator that can help you get up and running with very quickly by answering a few questions and then importing the generated code ( for frontend and backend ) in to your IDE.
Dec's Dom Blog 
The client side rendering frameworks also enable SPA’s (single page apps) and have an easier path to app packaging -both very important considerations in our mobile centric world. The bulk of innovation in UI work also seems to be happening in this space using npm or yarn packages.
LikeLike
Just came across this as a possible front end alternative. http://mithril.js.org/index.html Still investigating.
LikeLike
We thought long and hard about Client-Sided versus Server-Sided Javascript at Red Pill Now. Coming from an XPages background were were more familiar with the server-sided model (and its limitations). When we looked closely at the many of the really cool apps emerging we noticed they all had very responsive UIs, something that can’t be reproduced with server-sided partial refreshes. So we opted for a client-sided model. One that supported Web Components, because as you point out Declan there is a trap if you start moving from one framework to another. Web components allow you to reuse code in that situation as it is not clear if/when the world of JavaScript frameworks will pick a winner.
LikeLike
I would be surprised if there’s ever a true “winner” for a client-side framework; the best we can do is select what looks to be a well formed framework that fits your team’s given needs or expectations. Living in a post-React world keeps it interesting.
LikeLike
Eric, I agree with you. Choose Wisely
LikeLike
Declan, I would say spend the time to research what you expect your current and future needs are. Look for a framework that meets the needs and can be supported over a very long period of time. There are so many frameworks popping up that sounds cool and has great new features, but they come and go and new versions are not compatible with old versions.
LikeLike
I would like to know what made you choose server-side rendering over client-side. I agree with Peter that server-side response cannot beat client-side responsiveness. The users/customers could not care less about what technology the website uses. They care about user experience.
LikeLike
Great post, thanks.
With Collonies.com, we went client side, but we are still looking at some of these same questions. It’s tough coming from a Domino background where everything was so efficient and compact, and you have so much control on the server side to begin with, to go to the wild world of javascript frameworks and open source servers. My instincts still feel off a bit when I’m coding a client-side app and I still feel like I need to hand all the data to a server-side agent for processing, but it just wants to do that for me… I have to trust it.
What I have found though is, that with using the MEAN stack, that the convenience of tossing around JSON between the database and server and client has outweighed the security risks of the REST components directly calling to the app server. I can still cleanse and secure the data on the server side where I need to, but I can treat most of that data the same throughout the architecture. Javascript is javascript is javascript … I’m always talking the same language, and I get the benefit of handing off the Responsive Design tasks to tried and tested frameworks that know the clients better than I do.
All that aside, I think I’m really just going with the flow here a bit too… the variety of technologies that support client side apps, and as jakemono mentioned, the way we can package ‘single page apps’ in the large platform environment we have just makes things feel easier, and the developers seem much more comfortable with it, It bugs me not to have my handy ‘old school’ forms and views and agents setup, but the templates and ng-views and node have made it less painful for sure.
I look forward to reading more, thanks again,
Dave
LikeLike