Frontend Learning Notes 2 - Direction Shifted

My Confession

Only the ignorant person fears nothing.

I gotta say that I was way too over ambitious about the frontend stack. When companys like Google and Mozilla start to push the standardization of new innovations of the Web. The frontend standards keeps changing everyday, so does the Toolchain. Chasing the tool could be harmful, so I realised a realistic learning plan could be more benificial for me. After a few days of extensive research, my mind changed. The more I learn, I become less bold, so that I become more and more eager for a shorter learning curve. Compareing with “Flawless on paper”, I prefer a more practical stack. Here is what I learnt:

PostCSS => SCSS

I know the PostCSS is the future, and CssNext/preCss plugins appears like a great replacement of Scss. Also according to Boostrap & many others SCSS is way better than LESS. But then I find that if I want to custom and build Boostrap, I have to import SCSS anyway. So SCSS+Autoprefixer beat my original ideal buy ignorant plan.

Build Tool & Module Bundler

There is a little bit backgound I have learnt. - gulp beats grunt. - Webpack beats browserify beats RequireJS. - With the viral of NodeJS, CommonJs becomes the de facto standard importing syntax(I believe). It Beats AMD, CMD and otheres, moreover ES6 module is compatiable with it, so it is also future-proof.(Completely Wrong…explained below) - Webpack is capable to do some jobs of gulp.

I was thinking of using gulp + webpack. But since nowadays, webpack have plenty of plugins and loaders, and most importantly, I found at least 2 boostrap-loaders which claims that they can process Boostrap v4. I can simply say good bye to Gulp. I might meet you again, don’t know why, don’t know when, but I might meet you again some other day~

Webpack can minify Js, provide source map for dev stage, build SCSS, build typescript, build Vue/JSX, build Boostrap, include jQuery support without expose global access to it, process PostCSS(Autoprefixer), custom the dist path, watch the dev folder, live-reload. What else do you need? What else do you need? What else do you need?

Keep Practicing

It is the only way to reveal the imperfection of your tool and to pursue perfection of understanding at the same time!

Before practise, you won’t know if the tool is gonna suit your needs. That is exactly why I dropped the semantic UI, because it follows “Convention over Configuation”, so it has to sacrifice “Explicit is better than implicit*Refering to The Zen of Python

Before practise, you won’t know NodeJS have many dependency issue with Windows platform, so the Vagrant become mandatory! no longer Good to have. That is a good thing also, If I could compose my Vagrantfile.

Nevertheless, this is absolutely worth our attention. However, it is neither stable nor mature. https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-windows/

Again, references

NodeJS:

WebPack:

Vue:

Vagrant:

Page Load Effect:

Corrigendum

ES6 Modules is not an official recognition of CommonJS

ECMAScript 6 modules is a completely different thing, comparing with CommonJs.

Can’t believe how assertive I was.

References

comments powered by Disqus