3 ms·
It's been true in my experience. I've had interviewers scoff at me for mentioning Bower and Grunt, saying that the latest best practice was Webpack. Is Webpack
by quanticle 8y ago
It's been true in my experience. I've had interviewers scoff at me for mentioning Bower and Grunt, saying that the latest best practice was Webpack. Is Webpack really better than Bower and Grunt? It's different, that's for sure.
I get the feeling that a lot of the web development community has trouble understanding the difference between different and better. That's why we see so many wheels get reinvented so often. Is React a better way of manipulating the DOM than, say, Angular? I don't know the answer to that. It certainly is a different way. Is Webpack better at combining and packaging code than Grunt and Gulp? It's a different way of of packaging code.
In other communities, there's a much more nuanced discussion of whether technologies are appropriate. In the web development community, there's a much greater emphasis on painting technologies as absolutely "good" or "bad", "current" or "obsolete", without the suggestion that this new technology can coexist alongside existing technologies and address new use cases that the existing technologies didn't address. I've heard of numerous (and participated in two) projects which migrated from an existing framework (such as Angular, Ember, or Knockout) to React, solely because React was newer. There was no consideration whether React was a more appropriate framework for the task at hand. There was little consideration of the costs of the transition. It was a knee-jerk decision. "This framework is old, and the code written in it is nasty and buggy. We need to "refactor" (read: rewrite) our code to use React so that we can be current with the state-of-the-art best practices in web development."
I compare this with, for example, the Python community, where there is much more of a detente between frameworks like Django and Flask. Even though Flask is newer, there wasn't ever really a question of Flask replacing Django. Flask was merely seen as a solution for cases you'd have to strip out of a lot of Django (like its ORM and much of its middleware) in order to get a simple interactive website up and running quickly. There wasn't nearly as much of a push to use Flask because it was merely newer.
- ng12 8y ago> I get the feeling that a lot of the web development community has trouble understanding the difference between different and better I think you're confusing the HN community with the web dev community :) Everything I picked I picked because it was better for a specific reason. React solved the problems I was having with writing reusable code. Webpack takes all the grunt-work out of Grunt. TypeScript purely for the ease of refactoring. > I've heard of numerous (and participated in two) projects which migrated from an existing framework (such as Angular, Ember, or Knockout) to React, solely because React was newer. You can do this with any project The reason these choices exist is because lots of very smart people are thinking very hard about ways to do things better -- it's naive to think there's no merit to them because some people you happen to know are making poorly informed decisions.
- quanticle 8y ago>The reason these choices exist is because lots of very smart people are thinking very hard about ways to do things better Well, that's one way of thinking about it. Another way of thinking about is that it's a lot easier to gain recognition and mindshare for releasing a new framework than there is in refactoring or implementing improvements upon an existing framework. This incentive structure applies at both the corporate and individual level. I've found, from my experience working at large tech companies, that many frameworks get started because a senior engineer wants a demonstrable project to demonstrate their leadership and technical skills in order to get a raise or a promotion. A new framework is definitely a high-impact project with a very clear deliverable and a well-defined set of requirements. So they make a new framework and then market the absolute daylights out of it, since one of their goals isn't just to create a new framework, but also to demonstrate some level of adoption for it. So the framework is pitched as the next big thing, which makes all existing frameworks obsolete. Scale this motivation and approach up to the level of corporations rather than individuals, and you have the modern web development ecosystems. Corporations want goodwill and mindshare, and they know that one of the ways to get that is to release a framework that everyone uses.
- ng12 8y agoThat's a nice theory but I think it's wrong. Can you provide an example of a framework that should have been an incremental improvement (or not written at all?). The only possible example I can think of is React vs. Vue, but even then there's a pretty fundamental differentiating factor which is that Vue is lightweight (e.g. easier to drop in to an existing non-Vue project).
- rambojazz 8y ago> I've had interviewers scoff at me for mentioning Bower and Grunt, saying that the latest best practice was Webpack This is how you know you don't want to work for them anyway. Putting "best practices" before requirements...
- lowercased 8y ago>Is Webpack really better than Bower and Grunt? IIRC, grunt/webpack would be the comparison. bower is more of a package manager (akin to npm), no? bower has been deprecated (from a year ago or more, no?) Worked on a project in 2015/2016, set up the project with bower, and I noticed by early 2018, deprecation notices kept coming up in the build logs. Not a major crisis, but I wouldn't start a project with bower in the mix today. re: newer/better - I know some folks who transitioned to react from other stuff, and it really is 'chasing a trend', but their goal was primarily to be 'relevant' because they are specifically trying to attract a certain type of developer (IE, one that is focused on the newest stuff), because they think they'll get funding or more cachet or something else along with it (move in the right circles and you're a bigger target for acquisition?). The opposite of this is a current project - a slapdash offshored project using codeigniter 2 (and was started in 2016, IIRC, well after CI2 was EOL). There's dozens of bugs, and fixing each one involves far more time than a rewrite would involve, but ... "it's working, and we don't want to rock the boat or lose momentum or...". So there are projects which chase the latest trends for the wrong reasons (and maybe sometimes legit reasons), and there are projects that cling to the past for bad/poor/wrong reasons. I'm not dogging on CI2 specifically, but the fact that we've got a pile of broken code that, even when 'fixed' will still only work on PHP5.