Frontend Learning Notes 2 - Direction ShiftedApr 3, 2016 · Comments
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:
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 (Completely Wrong…explained below)
- Webpack is capable to do some jobs of gulp.
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.
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?
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
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/
- What is Node.js Exactly? - a beginners introduction to Nodejs(YouTube)
- Getting Started with webpack(YouTube)
- Webpack Tutorial - Replace Gulp/Grunt plugins with a single tool(YouTube)
- 一小时包教会 —— webpack 入门指南
- Webpack傻瓜式指南（一）- 张轩(知乎)
- Webpack傻瓜指南（二）开发和部署技巧- 张轩(知乎)
- Ruby Programming in One Video(Youtube): In one video series is great for syntax-learning.
- VAGRANT DOCUMENTATION
Page Load Effect:
- ContentLoaded(2010) A page load library,used by webpack.github.io
- Animated page trasition Worth investigation
- History.js Need no introduction
- Non-Jquery Page Transitions lightweight A great proof of concept
- TurboReact A react based implementation
- Turbolinks extraction of above solution, the best library to use by far
ES6 Modules is not an official recognition of CommonJS
ECMAScript 6 modules is a completely different thing, comparing with
- First of all, ES6 Modules are statically loaded!!!!
- Then It requires all the dependencies to be fully imported at the beginning.
- So that the tricks like
tree-shakingbecomes possible. (AST parsing becomes much more effient and easy)
- There is performance improvement as well.
Can’t believe how assertive I was.