Friday, January 27, 2017

Time to change

In year 2012, when I joined Moxtra to work on Front-end Web app, I didn't know anything about Javascript, CSS or HTML5. I was using Java/J2EE while in Cisco. At that time, I googled a lot and made the following choice for Moxtra web app architecture in a short period of time.
When look back, the selections were ok at that time. However, Web front-end evolved rapidly every few months, and in past 4.5 years, there are many new ideas, frameworks, libraries, and tools created for the community while major browsers are upgraded in a rapid pace to fully supporting ES5 and partially supporting ES6. (http://caniuse.com/)

Today I read a blog https://risingstars2016.js.org/ which listed popular front-end projects/libraries in 2016. I am totally terrified to see so many new things happening.

Popular lib/frameworks
Node.js Frameworks -> Express, Sails, Loopback, Restify
React Boilerplates -> Create React App, React boilerplate
Mobile -> React Native
Transpilers -> TypeScript, Babel
Build Tools -> Webpack, Gulp
Testing Framework -> AVA, Jest
SSG (Static Site Generators) -> Hexo, Gatsby

Most popular projects on Github
Vue.js
React
Yarn
Angular 2
Electron
Create React App
React Native
Redux
Boostrap
D3

Time to change:
ES5 -> ES6
Backbone -> Vue.js/React
Requirejs -> Webpack
Grunt -> Gulp/Webpack
Sublime -> Atom/Visual Studio Code
Mocha/Jasmine -> AVA/Jest
NPM -> Yarn

Tuesday, January 17, 2017

Semantic Versioning

Nodejs, bower etc all use Semantic Versioning for release version management.

Semantic Versioning, its main idea is to define the versioning rules for product release. It has 3 parts:

Major.Minor.Patch (x.y.z)

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

When we give the versioning, we need follow the rules. Initial development is suggested to use 0.y.z till it is ready for production (1.y.z)

When we declare package dependencies, we have different kinds of formats.
  • latest -> Takes the latest version possible. Not the safest thing to use.
  • ~1.2.3 -> Any version “reasonably close to 1.2.3”. This will call use all versions up to, but less than 1.3.0
  • ^1.2.3 -> Any version “compatible with 1.2.3”. This will call versions up to the next major version like 2.0.0. Could break your application if there are major differences in the next major version.
  • 1.2.3 - 1.2.5 -> Anything within a range of versions. The equivalent of >=1.2.3 and <=1.2.5
  • * -> Wildcards. Can be any version at all. 
It is highly recommended to use ~1.2.3 format when declare package dependencies.
It is highly recommended to follow semantic versioning rules to define your owner package version.