Hacker News new | past | comments | ask | show | jobs | submit login

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 use yarn by default now. I don't see a good reason not to have deterministic dependency management and lockfiles.


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?


> 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.


Gulp and Grunt were essentially wrong. Using a task runner as an asset pipeline makes no sense. A lot of things, like doing incremental compilation of Sass takes 100+ lines of Gulp crap to do, while it's the default in webpack.

Browserify was nice for simple cases, but getting it to do what's needed in a large, real world application was really difficult. Lately it has a lot of those features, but when Webpack became popular, it just didn't.

I started using Webpack after doing a length cost/benefit analysis and settling on.....gulp + browserify, because WebPack looked too complicated and people in the team had experience with browserify. After a week of trying to get it to do what we needed, I tried WebPack again and did it in an afternoon. That's when we switched.


> Gulp and Grunt were essentially wrong.

They were not wrong, but they do a general automation (and sometimes it's needed), just a task runners and a wrong thing was to use them for web building automation collection scattered over the internet stuff together into the complex framework. So every team or project had own framework, which means no standard, and that's a bad thing. Webpack allows to defined a needed behavior in a kind of declarative way since it has a structure.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: