Tools for the applications of the future

The web platform is the future. Web tools are the tools of the future. Desktop applications will continue to live, but will slowly die, to be replaced by browser-based applications. Likewise on mobile. Platform-specific mobile application development will fade as it becomes easier to write applications that work everywhere -- for devices small and large.

The magic buzzwords these days are "responsive" and "progressive apps.

Responsive is a design principle for HTML pages that:

...adapts the layout to the viewing environment by using fluid, proportion-based grids, flexible images, and CSS3 media queries.

Progressive is a design methodology that:

produces an evolving hybrid of regular web pages (or websites) and a mobile application. This new application life-cycle model combines features offered by most modern browsers with benefits of mobile experience.

Progressive apps are responsive, and a lot more. The characteristics are listed here. The applications that I want to design are progressive apps.

Embedded applications will still exist, and need to be written in C (for example) and run on bare metal. So will high-performance special purpose applications. But user interfaces and control applications and test frameworks are needed for these applications and they will all be built on web technologies.

So mastering these technologies is the key to future success.

The architecture for future applications is this: a set of components, communicating with one another over networks. Two components might run on the same machine or they might be, literally, worlds apart. Well not worlds, not yet. But certainly on opposite sides of the globe.

This architecture includes web-based front-ends talking to cloud-based back ends -- the classic client-server architecture. It also includes microservice architectures, in which monolithic services are decomposed into smaller, communicating component parts. It includes services -- like Service Workers and Web Workers -- that run on client browsers.

The Open Source community, both corporate and individual, is driving innovation at a rate I have never seen before. There are so many technologies, so many options, it's hard to choose. But to turn what I've been doing from a set of research projects into a set of products, it's time to choose among competing tools, and dive deep into the ones that I've chosen.

• Git for configuration management
• Docker for platform-independent components
• Docker Compose to manage a fleet of containers
• Maybe dropbox to back stuff up that doesn't belong in Git. Maybe.

Those things need to be installed on your host. Everything else runs in Docker containers. Which means it runs anywhere you've got a Linux, Mac or Windows system. This leaves Chromebooks out, for the time being. But that will change.

Some details:

• Git for configuration management. Almost all open source projects are hosted on Github, and Github credentials open the doors to many other resources; Github also will host your open source project for free, and closed source for not too much. BitBucket has free plan for closed-source, with limits that work for a small project. The Docker files and Docker Compose files for the project will all be stored in a git repository. So git must be installed on the host.
• Docker: platform independent containers. This will be used for development conmponents, development data, and for production components and data. Every component will run in its own container. Data will be stored in containers. Data containers will be backed up to the cloud. So Docker Engine has to be installed
• Docker Compose: a tool for running multi-container applications. So one Docker Compose configuration will build (as needed) and run an entire assembly. So Docker Compose has to be installed. 

These are the core technologies that need to be understood (and possibly mastered):

• HTML5, CSS3, Javascript  This is underlying technology for modern apps. I like Jade instead of HTML for readability, LESS for CSS for readability and functionality; I had preferred CoffeeScript to JS for readability and conciseness, but ES6 has adopted many of CS's features, so may use that.

These are the development tools that will need to be installed in Docker containers. My working theory is that each can be installed in its own container, with Docker Compose making the connections among them. But we will have to see:

• Atom: Extensible editor built using web tools and the best ideas from previous editors. Speaks VIM and Emacs if that's your fancy. Tons of plugins to make life easier. Runs in a Docker container. The trick (which I will write about) is saving settings.
• Chrome (or Chromium): Chromium is the open source base; Chrome is the Google-branded version. 
• Brackets:  
• NodeJS for server side. Node runs Javascript, which means that some units of code can migrate between client and server. Current verisons of node support ES6.
• NPM for server-side package management. Plus a bunch of packages.
• Bower for client side package management.
• Grunt or Gulp (TBD) for build support.
• Polymer: web components, which encapsulate HTML, CSS, JS in reusable, framework independent 
• Plunkr: great tool for fast-response prototying on the web.