I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.
It happens all the time because most UMD implementations are broken and make incorrect assumptions, so you often have to follow the "Fix broken modules" steps on https://webpack.github.io/docs/shimming-modules.html
And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one.
That's more a problem with the state of broken UMD modules than Webpack itself though, but I've considered configuring webpack to ignore all AMD syntax quite a few times...
Yeah the line of thinking seems to be that everything else is broken, not webpack. And the module maintainers say "well it works with everything else except Webpack so webpack is broken, they should fix it." Seriously crap situation.
But people should code for Webpack or JSPM or require JS or whatever. A good solution should just work no matter how the lib was coded, if it doesn't then the solution isn't worth the investment.
If you mean old jQuery plugins or libraries that aren't CommonJS compatable, Webpack even has your back on that via its various plugins.
I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way.
I'm trying to program an application, not Webpack. If there are plugins that solve some problems then why aren't they part of the default config of webpack?
I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure them. I just want the module that I need to function.
Most people don't need these things. And more and more companies have devops and infrastructure teams that can deal with that.
We're still in a world where every team is a snowflake (the closest things to breaching that was Rails and other server side MVC frameworks similar to it). Once the tech slows down a bit, you'll probably see better solutions.
That being said, dealing with legacy code always always suck.
I'd wager a bet that most people using JS today are nowhere close to having devops and infrastructure teams, but are still single people in their bedrooms copying and pasting stuff from Stack Overflow trying to make their online flower shops work.
For the life of me I cannot remember who it was, but somebody once essentially said that Javascript had the quality of allowing anybody to bring to life what's in their head, no matter their skill and experience level. You could almost mash the keyboard until it worked.
For me, this is a democratizing quality which is fundamental to the spirit of the web, and I would be more than happy to give up generators and class keywords for it.
I've recently spent over six hours trying to build and use a JS library, fighting with package managers, build systems and transpilers, whereas earlier all I would have need to do was download a file and include a <script> tag. We're not moving in the right direction.
The reality is that these tools, eventually, are used by businesses trying to build stuff efficiently.
If we were to have a hackathon, and I could use the stack I have at work (which contains some of these tools, plus our own secret sauce), I'll trash anyone who's using script tags on a page.
Things like webpack, commonjs, npm, etc, are ways to bring that to everyone.
If you're making a little one off or a small project, then anything you're comfortable with will work. Heck, go and use a tool just because you like the logo. It won't make much of a difference.
I feel like if you are trying to make your online flower shop work, you probably shouldn't go near any where near any of these libraries. I think they are for experts who are working on large projects, probably 30,000+ lines. For the casual developer, use a script tag and go sell some flowers. I love that you can do that with Javascrpt, it's really easy to just write some code, so many fewer things to worry about for the beginner/intermediate than languages like Java and you can be so much more productive at the non-expert level.
Exactly, or better yet just use a saas ecommerce / blog /cms software package which gives you a lot of customizability without any programming like wordpress, wix, etc.
It took me a while, but I'm now a big fan of React, Webpack, Babel, etc. That said, I had to make a little project yesterday, and I through 5 script tags on it, on of which was jQuery, and everything was fine. All of these new tools don't stop you from using what worked 3 years ago. I don't think allowing for more complicated set ups means it's less democratic. It just makes certain projects available to single developers, that would have in the past required a large team.
I agree though that the vibe is different. Newcomers feel less welcome. I think by the end of this year, we will see a layer of abstraction over a stack similar to the one described in this article, and that it will be the new jQuery, in terms of letting a novice developer make something surprisingly powerful. At least I hope so.
Agree we definitely need a stack that integrates all the best of breed tools for this stuff. There's some good boilerplates out there, which almost gets there, but it's not quite the same. I've considered building one. I think it would be especially interesting if it supported server side rendering out of the box and tightly integrated with aws lambda, aws api gateway, and the serverless framework.
