Fun fact: Web Components are completely oblivious of ES6 imports/exports and all PRPL examples basically assume modules are dumb JavaScript code that can be loaded from script tags, completely ignoring the trend towards JS modules JS has seen over the past five years.
I wouldn't touch Web Components with a ten feet pole until the dust has settled and someone has come up with a convincing solution that is more workable than bower's "version conflicts are verboten" approach to conflict resolution.
Stepping back for a second and looking at other programming languages.
Not really, unless you only consider languages that have become stagnant (so there are only a few options left and no new ones pop up) or that haven't gained any traction (so there are only a few options around in the first place).
Considering the size and openness of the JS ecosystem (i.e. its strong tendency towards open source at every level) this is perfectly sane and expected.
If you want to pretend there are fewer moving parts, just use a TypeScript/Angular2 boilerplate and hope the single framework solves all your problems.
"Beginners". How long will this take to learn compared to just vanilla JS and maybe a basic framework. Obviously a bit longer. Try explaining some of the benefits to the beginner.
What is the need of gulp for the Webpack set-up? I am talking here about "9-Webpack" project, we can achieve that without the gulp just by setting up the Webpack with relevant packages, right? I am not a big fan of combining Gulp + Webpack. It's already complex and what is the need to make it more complex adding one more to the mix. I appreciate your insights.
Hi, author here. The goal for Gulp - even in the Webpack chapter, is for back-end transpilation. Webpack is great to replace Browserify for client apps, but Gulp is better suited for back-end stuff in my opinion. I also wanted to show people the specific part that Webpack replaces (the Gulp 'build-client' task) to give them a clear idea of why we introduce it.
17 comments
[ 2.7 ms ] story [ 56.9 ms ] thread[1] https://www.w3.org/standards/techs/components#w3c_all
I wouldn't touch Web Components with a ten feet pole until the dust has settled and someone has come up with a convincing solution that is more workable than bower's "version conflicts are verboten" approach to conflict resolution.
Myself? I truly wish Netscape had gone with Scheme instead of the weekend hack that became JavaScript, as they'd talked about.
[0] https://news.ycombinator.com/item?id=12628921
Not really, unless you only consider languages that have become stagnant (so there are only a few options left and no new ones pop up) or that haven't gained any traction (so there are only a few options around in the first place).
Considering the size and openness of the JS ecosystem (i.e. its strong tendency towards open source at every level) this is perfectly sane and expected.
If you want to pretend there are fewer moving parts, just use a TypeScript/Angular2 boilerplate and hope the single framework solves all your problems.
It's still there. But as always, "hello world" is not even remotely close to what a real-world project would look like.