1 point of minor interest is that they start by using Yarn, not NPM. Little things like that (esp from a major project like Webpack) can develop into definite trends.
Maybe the author is trying to make Yarn a trend?
11–20 of 59 posts
1 point of minor interest is that they start by using Yarn, not NPM. Little things like that (esp from a major project like Webpack) can develop into definite trends.
Maybe the author is trying to make Yarn a trend?
1 point of minor interest is that they start by using Yarn, not NPM. Little things like that (esp from a major project like Webpack) can develop into definite trends.
I currently use gulp and, over the yars, have found many ways to do my own parsing and smart caching and stuff over, like checking and bumping version numbers, conditional compiling, caching assets etc. I'd hate to loose all that, but I do see the advantages of Webpack. How much control do I have with Webpack though? Can I still write my own hooks?
Interestingly, things seem to be settling down in the JS community. In the past, every time a library lacked a particular feature, the community suddenly abandoned it. At the same time, every new version release had all sorts of horrible breaking changes, that made upgrading a very scary task. Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least fr…
That's exactly why the blog post suggests using yarn instead of npm, isn't it?
1 point of minor interest is that they start by using Yarn, not NPM. Little things like that (esp from a major project like Webpack) can develop into definite trends.
I found the inclusion of Yarn in this tutorial to be misplaced. Adding another step to what is already considered a complex library feels unnecessary. Maybe the author is trying to make Yarn a trend?
The JavaScript community makes me a cranky old man, because yarn is even a very good idea and solves actual problems. Still that was the point in the article where I thought "fucking JS hipsters". No time to play with tooling, when there is actual work to do.
Especially with other people in your team, whose time costs actual money, I think standardization of dev environments and tools trumps almost every new feature (as long as you were using tools in the first place).
I have seen the talk (I believe it was from Instagram), which showed how Webpack could work with shared code and so on, but still: Browserify and Gulp were already working (and I believe can now do the same thing) and even Gulp has only very marginal benefits over Grunt in my opinion. I would love to go a few steps further back, but "installable via npm" is just a crushing argument against Makefiles.
Interestingly, things seem to be settling down in the JS community. In the past, every time a library lacked a particular feature, the community suddenly abandoned it. At the same time, every new version release had all sorts of horrible breaking changes, that made upgrading a very scary task. Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least fr…
> Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer. That's exactly why the blog post suggests using yarn instead of npm, isn't it?
Earlier quoted context omitted.
> Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer. That's exactly why the blog post suggests using yarn instead of npm, isn't it?
Have you used yarn? Do you know what it is? It's a fully backwards compatible client built on the npm packaging system, using npm's repository, and built in collaboration with the npm team.
I currently use gulp and, over the yars, have found many ways to do my own parsing and smart caching and stuff over, like checking and bumping version numbers, conditional compiling, caching assets etc. I'd hate to loose all that, but I do see the advantages of Webpack. How much control do I have with Webpack though? Can I still write my own hooks?
I currently use gulp and, over the yars, have found many ways to do my own parsing and smart caching and stuff over, like checking and bumping version numbers, conditional compiling, caching assets etc. I'd hate to loose all that, but I do see the advantages of Webpack. How much control do I have with Webpack though? Can I still write my own hooks?
By writing your own, you can hook into pretty much everything you could possibly want.