REF projects REF blogpost Appendix References H2 Prologue H2 Introduction Have you been following the software development scene regarding web applications? Well, I do for quite a while and I have already built quite a few web apps, native apps and websites. Unfortunately, that scene is extremely fragmented and it is difficult to make the right decision if you want to make your next web app. This applies to both B2C, B2B and Enterprise applications. Note that 80%-90% of all software applications in the world are Enterprise Applications so we should not limit ourselves to web apps for mobile only. The time has come again to assess the artifacts that are available to develop web applications and make a smart selection for the next project. INFO Please do not confuse a web app with a traditional website. A website is often best implemented using an off-the-shelf CMS such as WordPress with some extra JavaScript pushed to the client for some interactivity. If you need to customize the website a lot then a custom developed solution might be a better choice. If you need a lot of interactivity, be mobile friendly (visually and latency wise) then you better develop a web app for it. If you have read some of my other posts (xxx, yyy) that you will know that I have already put my bets on JavaScript as much as possible. The Classic MVC (server-side) frameworks have already been ruled out. H2 What are the parts of a web app? A web application consists typically of the following parts: The application shell. The view part of the frontend. The model part of the frontend. The orchestration components (frontend<->backend). The backend services. The data store (local or remote). The view part is the part that is most talked about on the Internet today although I sincerely believe that the other parts are equally important. The (web) application shell is typically a Single Page Application (SPA) with sits on top of the DOM, and some mechanism of componentization (hopefully Web Components compliant). The app shell can also be wrapped in a platform specific container, or accompanied with a manifest.json, to make it easier to run the app on various platforms; think and Cordova and Chrome App. The view part of the frontend consists of GUI components, HTML5, CSS3, model-view bindings. The model part typically manages a representation of your data (‘data’ can be data structures, business logic, …). The orchestration components ensure that the model can communicate with your data store or micro-services (public and private); either directly or indirectly via backend service(s). The backend services typically manage the comms with the backend data store and micro-services. The data store. I would like to opt for an RDBMS like MySQL, Oracle,… because most of the data that is used in the web app must also be accessible by other applications in the company (these are ‘traditional’ applications such as reporting dashboards in my case). If this is not required then a real-time database such as Firebase is a very good choice. H2 What type of solutions are, generally speaking, available? There are solutions that tackle one specific part, solutions that tackle several parts, and all-encompassing solutions (frontend & backend). A second classification could be if a solution is a giant framework (think Zend FW in Classic MVC but then for web apps) or a bundle of loosely coupled components. I deem it important in the case of loosely coupled components to know if you can grab these components from the same supplier/community, opposed to the situation where you need to shop at multiple suppliers which is always a higher risk in my opinion (example: use React and combine it with the GUI components of Kendo). Examples: React only covers the view rendering part of a application. Yes, you can also put other React related libraries in this equation but I’m not going to do that (see later). Meteor tries to offer a one-stop-shopping solution for developing web apps and I think they are good on their way to become a major JavaScript Application Development Platform. H2 The view part of the frontend Enter Angular[1|2], Aurelia, Ember, Polymer, React, … (alphabetical order). I have evaluated each solution using the following general criteria: Market footprint. Usage in real world applications. Quality of the documentation. Standards compliance (Web Components anyone?). Maintainability of the app (consistency of the code, %plumming code). I have evaluated each solution using the following technical criteria: View-Model implementation. GUI components. Routing. Data validation. Internationalization.
Tagged with →