These tools aren't the simplest things, but so is everything, everywhere. Complexity needs to exist somewhere, and using an abstraction to hide them is something natural. Do people think we shouldn't use compilers because we 'can' write binary ELF files directly? Same goes to JS.
Here's two excellent articles that go over the history and use cases behind the JS tooling ecosystem:
http://tinselcity.net/whys/packers
https://www.swyx.io/writing/jobs-of-js-build-tools
As a counter-point, there's also valid reasons why a lot of the JS tooling ecosystem is painful to work with:
https://increment.com/development/the-melting-pot-of-javascr...
https://www.swyx.io/writing/js-tooling/
For myself personally, I'm quite happy with the React ecosystem. For the kinds of "desktop-app-in-a-browser" apps I work on, it's fantastic.
(Caveat: I'm a Redux maintainer, so I'm also a bit biased here.)
I've written and maintained several jQuery applications and if I'm being honest, I much prefer it over all the tooling we have today. jQuery isn't perfect because nothing is of course, but with a little discipline I never really had any trouble maintaining a jQuery application. In my opinion, all the tooling we have today does is obfuscates me away from my code and actually makes it harder to maintain.
I find that a strange attitude. Complex systems are by definition harder to reason about, and therefore guaranteed to contain more bugs given the same amount of mental effort.
Sometimes complexity is unavoidable, but in general I find myself attracted to simpler systems, and consider that a sign of good engineering rather than the other way around.
Death to complexity on the frontend for complexity's sake.
(I wanted to paste it, but it's too long = 2500 lines)
> I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order.
Okay, so I've never worked in Angular, so I can't really speak (maybe there are Angular killer features that justifies using Angular?), but... If it looks like it'll be simpler in ASP.NET pages, go for it!
Everybody likes lighter pages, if your app is simple * doesn't need to be a heavy Angular SPA, you shouldn't be using them.
So for us Java developers it was great. I don't know about Angular 2 and beyond, but I'm sure it has its place.
Either way, I can confirm to OP's findings with Angular. I worked on an Angular project not too long ago and every time I hit Command-S I had to wait 10 seconds before the page would refresh. Manually refreshing wasn't an option, of course, because it was busy compiling. I tried to explain to my client that those 10 seconds were quickly adding up considering what my billable rate was but they didn't seem to mind. It was from Google and that's all they needed to know.
Death to remaining in the dark ages for nostalgia's sake.
A lot of my issue with the Javascript-heavy present of "modern" SPA websites is that they have to recreate native browser functionality, which is inevitably slower and worse.
Way too many websites could have the same functionality, in a simpler form, with better performance with a more "traditional" stack. You can even have your API separated front-end and back-end via server-side rendering (by which I mean old-style server-side rendering).
The modern zeitgeist is mostly hype, fad, and novelty.
Our frontend Angular test runs take 25 minutes to run less than 2,000 unit (not integration) tests. That's just nonsense. I don't blame Angular so much as I blame the JS ecosystem. For comparison our backend unit test runs (ASP.NET Core) take 3 minutes to run 6,000 tests.
You can argue we're doing something wrong, but as a company with a a thousand or so devs - reaching out to the most experienced frontend devs we have, their answer is: you've got too many tests, split up your SPA into smaller SPAs. Great, more complexity and dependency management hell.
I can't wait for Rust/WASM to eat Javascript alive. I'm considering writing my next frontend project in Rust.
Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore.
anecdotally I got out of JS / frontend mid last year after many many years in it and felt at the time that I was burnt out and had lost my passion for development. Maybe it was just too long for me in one area.
I would argue that it's an absurdly overblown issue. The "costs" are a clear net gain which is why these tools are all but ubiquitous. Developer hype only goes so far, these tools are a proven success across every major tech company with a front-end presence. All this supposed complexity is a holistic improvement over the past, especially because all the same libraries and techniques from 20 years ago and everything in between work exactly the same way today.
> Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore.
Sounds like literally every piece of corporate software I've worked on that's older than 10 years. 10 year old php app? 15 year old c++ app? 15 year old vb6 app? 15 year old c app? Those are all examples of previous nightmares I have experienced and none of them were any easier to handle than a shitty angular mess. At least the browser is incredibly resilient with regard to failure states... try debugging intermittent crashes in a legacy c++ app preserved in a tacky lacquer of clever templating voodoo; nothing in js land even comes close to my time in the c++ insane asylum.
> That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools.
Well, the complexity is because webpack/gulp/grunt are do-everything tools. There are lots of features to assist everyone, and usually if you have some obscure requirements, webpack has an solution.
Yeah, webpack is complex - IMO one shouldn't use webpack just to bundle up JS files. There are opinionated tools like Parcel or CRA(which automatically configures webpack under-the-hood), and those will fit 90% of the users. Only the left 10% which existing opinionated solutions cannot accommodate can fiddle with the webpack config directly.
> Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project.
Well, do you really think JS has low-quality tools? I really don't see them as low-quality... And you should know npm/yarn before starting a JS project; it's like knowing gcc/clang before starting a C project, or knowing cargo before starting a Rust project.
> The complaints are more than valid when there are tools that do the same job without the unnecessary complexity.
(Assuming you're talking about npm/yarn) If you can do the same job without all the dependencies, you don't have to know package managers. If you want to, you should know the package managers.
As far as webpack, I understand that it's a jack of all trades. But if even trying to replicate a simple bundling config takes many days, then it's a perfect example of a tool that's not only overly complex, but one that doesn't do its own core job well.
It's incrediy subjective obviously, but in my 25 years of web dev (full stack) rendering speed has been the number one gripe from users. I've spent thousands of hours optimizing web things. The biggest impact on user perception of speed was the move to Web 2.0 eg JS apps that fetch data with 'ajax' and update the DOM.
If my experience is anything to go by users absolutely prefer client side rendered apps (with SSR, hydration, caching, memoization, optimal data structuring, etc, etc).
No doubt a huge amount of client side JS is garbage, and users would be better served by a server rendered website than a bad client side rendered app, but they'd be even better off still with a good client side rendered site.
If a combination of back-end processing with some vanilla javascript, or jquery will get you to market for your first 100-1000 users (which, we know it will because that used to be the only way we could do things, on much less powerful hardware no less) then I say go with that. In the mean time you can work with the stakeholders to put together a strategy for scaling up as demand increases.
- Auto-browser reloading.
- Minification and compiling all JS/CSS into single files.
- Partials for Header/Footer/Menus.
- CSS/JS files versioning (the browser-caching issue).
Sure you can build a static website without all these niceties. But these are a one time investment (gulp+webpack) that you can re-use for your future websites and work.
No. An insanely complex Eclipse based Java product I maintained had hundreds of dependencies (including transitive), from a handful of vendors (> 20). Apparently, an simple JS app[0] can have 40000 packages (from hundreds of vendors).
This is insane.
[0] https://stackoverflow.com/questions/55416657/why-do-i-have-4...
The problem however is that JS is a perfectly fine programming language by now. Think about it, why are we still stuck with Webpack et al? It's because of inconsistent or missing support for modules / imports, or because of a risk that a JS feature you use does not work on a certain browser. And there's JSX of course.
JS is not assembly.
Do people struggle a lot with cross-browser issues these days? It isn't like it was back in the day, when basic stuff like the box model worked wildly differently in IE. And almost everyone's on a rolling-release, auto-updated browser, so you don't have to worry about testing on old versions; even big websites like Stack Overflow only support the last couple releases of the most popular browsers: https://meta.stackexchange.com/questions/56161/which-browser...
I still test on multiple browsers, and every once in a while I'll need to fix a bug that only shows up in one browser. But JavaScript frameworks and build tooling don't really help with that, do they? (Am I missing out?)
People will browse your app from ancient mobile phones. Weird smart TVs. play consoles. Chinese browsers you've never heard of but come bundled with some we-something, they will browse your app from PoS, from a DJI smart RC, from a fridge. And from IE6.
And you know what's the best way to mitigate all that mental load? You just start upfront with a framework that was already battle-tested on all these weird browsers.
Safari never fails to make you question why, and Firefox and Chrome still have enough differences to catch you off-guard from time to time.
There are way too many small bugs and incompatibilities like these, and way, way too many browser versions still seeing use by at least a small percentage of users, to worry about them individually, unless you want that to eat up all your time.
So your choice is between "be okay with a broken experience for some users", or "use build tools to compile to a common-ancestor target of near-universally-supported CSS and JS".
1. the most of JS tooling stemming from browser compatibility issues does not mean that the issues still need to exist at the point that the tooling was established - it can take a while for established stuff to be moved out.
2. I think for most sites it isn't a problem, but for me the last 3 years has been work on big SPAs that need to generally also handle IE9 (degrade gracefully). And there is always stuff going on.
Yes but designing the right abstraction is an artform, and I suppose that these tools haven't yet found it.
Not really, and not even something that pertains to "really old" browsers.
As a somewhat recent example, in order to implement "SameSite=None" properly, one has to ensure it's _not_ sent to browsers (including recent Safaris and Chromes) which implement it badly. See also: https://www.chromium.org/updates/same-site/incompatible-clie...
But now this tooling is out of hand. I threw up my hands and found sanity again in simplicity (my username namesake).
* Django
* jquery
* intercoolerjs (https://intercoolerjs.org)
* plain old docker
Now I deploy apps with no more than 100 lines of JS.
Again, not prescriptive, just my own journey.
But I kept getting mired and "stuck" in how I should architect things, or what framework to use, or this or that. I eventually decided that I wanted it to be a browser-based app of some sort (thus the road of ES6) - but then I started to wonder what tooling to use there. Lots of questions, etc - and I never got that far with it.
I eventually wised up and realized that it didn't matter what I chose - what I needed was the application to work. Who cares about frameworks, requirejs, css frameworks, etc - I just wanted something working. So I stepped back...and decided to chuck all of that away.
I ended up with a basic webpage, with a script tag and the code inside that - nothing fancy, purely procedural, old-school javascript functions, tied to events. Bare bones, basic.
...and I made real progress for the first time.
Basically, by regressing to the relative simplicity of Javascript back from the 1990s, I was able to get my tool finally going, without having to worry about the last two decades of cruft around that language. Now, I could have also done it using Python or anything else, in the same manner - but again, I wanted it to be browser based.
As you note, my own journey, and not something I'd tell anyone else to do (and certainly not something meant for a production environment!) - but for myself, and my need, this fit the bill. I'm still working on it; I figure when I complete it proper-like, I can go back and refactor it to something more respectable. Or maybe not.
After all, if it works, why try to break it? In the end, I want the results from the tool - who cares what it looks like under the hood, so long as it works.
After playing around with some react/vue/express/angular/younameit apps for various clients I am more than happy to escape the dependency hell and write efficient code in pure JS that load basically instantly and doesn't need a build environment in the first place. The last straw for me was spending over a day trying to find the right versions for node and all the packages involved to at least get a "legacy app" I inherited running.
I find that I don't even need jQuery anymore, support for things like closest() or a simple document.querySelector is so good that I save those few kb as well.
I've written some reasonably complex apps this way, but I'd probably have a hard time selling this approach to fellow devs, most I've worked with are very entrenched in <insert favorite framework here> and not particularly keen on doing things differently. I can understand and appreciate that point of view, and will acquiesce to the will of the team, but in the past year or so I've had the luxury of being the sole dev on most of the projects I've worked on so this is what I've done and it's been wonderful.
F5 is my compiler, it requires no additional configuration beyond what's already in the HTML, and it's super fast. I love it! :o)
Laravel NGINX VanillaJS/WebComponents (toying with Svelte right now) MariaDB
Fast prototyping, simple deployment, almost no time spent with tooling.
A recent example with too much tooling I had was with Root's bedrock+trellis+sage. They do make working with WordPress management for a developer (a lot less clicking that with normal WP setup). But the frontend setup, webpack, backend, browserify and all of that is so complicated and slow. I was able to set it up on one machine, but failed to git clone the same project on two others. Scripts would be missing, things wouldn't load etc. Nightmare.
With regards to tooling I agree it is too complicated. I really wish that everyone would coalesce around a standard set of tools. But it would be the equivalent of cat herding.
This complexity is out of hand. The worst is we now use yet more solutions (for example server-side rendering, which now needs its own Node server and it's yet another thing to deploy in addition to your main backend) just to try and dig ourselves out of the hole we dug in the first place. Imagine if we suddenly decided concrete isn't cool anymore and everyone should use duct tape. Given its obvious shortcomings we now waste time trying to make tape work, going as far as making concrete-reinforced duct tape and calling it the best new thing of the day... instead of just using the "uncool" concrete in the first place.
This guy has a point, for 90% of projects, you don't need React (those who tell you otherwise are trying to justify their career and position because from my experience most React/Vue front-end positions at companies are pointless and just add unneeded complexity).
War story time: a client was building a complex financial product (includes real-time automated trading, etc). The backend was finished but we couldn't test it because despit several months months the React front-end still wasn't ready and days were wasted on basic things like a signup form, displaying the 2FA QR code, user onboarding wizard, etc. Let that sink in for a minute: we could successfully decide when to make transactions worth millions of dollars automatically, but dug a hole so deep on the front-end that we couldn't do basic things that even the first iteration of HTML forms could do just fine 20 years ago. The powers that be didn't want to lose face so they still kept at using that trainwreck of a front-end instead of ripping the whole thing out and rebuilding it using HTML forms in a matter of hours. I didn't stick around to see if they ever finished the project.
Putting together your own light-weight system isnt hard if you are familiar with the problems these tools solve, but unless you have a site so simple that it shouldn't use react anyway, you'll want the power and features that these tools can provide (automatic source splitting for lazy-loading code on route changes, sane management of language files for internationalization, extensive linting rules for even non-js things like accessibility features in html / jsx, automatic image optimizatuon, etc).
http://dokku.viewdocs.io/dokku/
Dokku also uses(Heroku) buildpacks, which are becoming standardized:
LiveView is an alternate architecture to intercooler.js but with the same goal. There is a standard JS bundle that goes to the client that opens a websocket to the server. You annotate HTML tags (like intercooler) and then handle the events on the server. This is all abstracted away though so you end up writing a controller that looks a lot like a normal server side rendered page.
I have had a great development experience. The Wagtail core team are very active and helpful.
I've touched some vue.js too, but I just hate the direction everything is going. These projects are just insanely complex. Component frameworks may be easier to develop with, but they add so much damn bloat and crazy amounts of tooling. I get frustrated enough with Jekyll and that's just a static content generator.
I really miss the simplicity of plain old jQuery and some backend.
If this direction of simplified web development is something you're interested in, you'll enjoy this post I wrote back when we started this project (and it was called @pika/web): "A Future Without Webpack" - https://www.pika.dev/blog/pika-web-a-future-without-webpack/
Disclaimer: I created Snowpack & Pika (pika.dev).
I would use a framework that did the majority of its magic on the back end and emitted either zero code that needs to run on the client or completely gracefully degrades when the client refuses to run untrusted code.
Every day it feels more and more like the web is a tracking framework with the lowest effort content that will keep the cattle clicking than an actual platform that provides real value. Being able to switch off executing remote code but be left with a functioning web experience would go a long way to providing real user privacy, which is, of course, why I have zero hope of it actually happening.
I think what the guy you're responding to is after is similar to what I'd like to see: a front end that isn't composed of 20 years of hacks layered on top of each other because of poor initial choices.
Luke Jacksonn is someone who's done some interesting work in this space with zero-build-tooling sites: https://perf.link - https://github.com/lukejacksonn/perflink
https://www.pika.dev is built with Babel and TypeScript, so it's not technically "zero-tooling", but we still get almost instant iteration by skipping a "bundle" step during development.
We are just saying that we'd appreciate something that removes the need for webpack et al.
I'd personally kill for a much simpler (and faster!) webpack.
It's all well documented, so if you need further details, there's nothing magic about these tools.
If you really don't want to be bothered with it, just use create react app, vue cli, or angular cli. Some people aren't that interested tooling, I get it.
If you have the luxury to only care about modern browsers, do you need to bother transpiling? Every modern browser supports ES6 natively.
> and webpack collapses all the require(...) calls into a smaller set of files
Also less of an issue if you're using http/2 or http/3.
Is there a "preview of the future" framework out there that people can use if they want to see what a world looks like that doesn't have to work around old browsers?
In my particular case, my infrastructure team will not, and has no plans on, enabling HTTP/2 in our upstream servers. The joy of application development at scale. You can't get everything you want, unless you control it all. Things are too distributed for me to practically sell the team on HTTP/2.
If the hard part of your project is setting it up the tools you've picked are too complex for the problem you're trying to solve.
Sure, but what tooling choice do we have? Webpack is pretty much a standard and is expected almost everywhere, with rollup and parcel used here and there.
Try without them with jquery only and you'll hit some walls. You'd basically ending up by rolling your own stuff with something vaguely similar.
Sure you can do static pages all day, but the whole idea is maintaining state and stateful transitions.
I've had the exact same thoughts. For a long time, I was a big VueJS fan because of its simplicity and I could build really nice clean and fast apps without a bundler. When your app has few dependencies, bundling is overkill. For some personal projects, I didn't even bundle for production; still, it loaded faster and the user experience felt smoother than the vast majority of web applications that we have today.
Now I can see VueJS is moving towards TypeScript and forced bundling. It's beyond frustrating. It's refreshing to read comments like above because so few people are experienced enough to see it as a problem. There was a period in front end development a bit less than a decade ago when it felt like things where always getting better every year; bundlers were only used for production for some projects and HTTP2 was going to allow us to push scripts to the browser so that we wouldn't even need to bundle for production... The future was bright. Then Webpack came along and it became crazy popular, then suddenly people started bundling during development? WTF! Then CoffeeScript came along, added essentially no value at all but people were crazy about it, then transpiling and bundling during development became completely normal. I never thought I'd live to see the day that people would be debugging machine-mangled code. All the work that had been done before since the invention of the computer was about making machine code more readable for humans so this was a shocking reversal of progress.
Most younger people think that bundling is normal... Always existing kind of thing. They don't realize that bundling and transpilation is a massive hack that was meant to be temporary and really should never have existed.
Very experienced engineers from previous generations invested a lot of time and effort into making fast interpreters for dynamic languages like JavaScript so that people didn't have to wait for code to compile. I remember watching interviews with Google Engineers who worked on V8 thinking to myself how great it was that they were able to get interpreted JavaScript to almost match the performance of compiled languages like Java; that was a huge achievement. Waiting for the code to compile was considered a major problem back then; especially for front end web development. Let's face it, the underlying problems of front end development are trivial, but the ecosystem itself has turned simple problems into highly complex ones.
If you've used programming languages like C/C++ where you have to link static and dynamic libraries together, the value of a fast interpreted language is very clear and JavaScript fits the use case quite well. Front end development was never rocket science though it seems to be getting there.
Now people added a massive, highly complex and poorly thought out bundling and transpilation layer between the efficient browser engine and their web apps which essentially takes away all the value and efficiency that had been thoughtfully and painstakingly added to all the layers underneath since the dawn of time.
Then people start complaining about how bloated and bulky and difficult software development is, but before we can all realize that the answer is to throw out all the unnecessary crap that was added on top, some genius will come along out of nowhere with hot new technology which will add even more crap on top and which gives the illusion of solving the problems that people were complaining about but it will in fact cause new, even worse problems... and the cycle of bloat and disappointment will continue.
But at least we will all have more jobs... For a while.
I swear if this industry gets any more retarded, they'll be able to replace us with monkeys. Some genius with an MBA will figure out that same productivity with lower costs = higher profits.
Vue.js using TypeScript doesn't mean that you'll have to. You can continue to ignore it and enjoy using plain old JavaScript (albeit with more informative feedback in your IDE).
Also, you'll continue to be able to include Vue.js with a <SCRIPT> tag, as easily as you did jQuery.
This is helpful if you want to get some reassurance right from the source: https://www.youtube.com/watch?v=WLpLYhnGqPA
My satisfaction as a software dev has increased massively since I've renewed my focus on the backend, and also spent some time with Java and other mature languages.
We still get things badly wrong but at least it's wrong in a way I can understand. I've looked at some new frontend projects and I would have to learn 7 or 8 different abstractions, inside a monorepo, just to understand how to build a simple interface to a collection of APIs.
Fuck that. The churn is too high and you might wonder how people built GUIs at all when you look at a modern web-app codebase.
Oh wait. That didn't happen. What is preventing you from using only jQuery and "some" backend?
That's right. Just you.
It is an endless loop.
The first dot-com bubble resource wastefulness was spending so much money on networking gear. Every one had oversized expensive Cisco gear.
This dot-com bubble resource wastefulness is so many hundreds of thousands of engineering hours devoted to mega super over engineered Javascript solutions.
jquery-era code solved this by just putting the dependencies in the README of a project (e.g. "this project requires jQuery and jQuery UI version 3! load them before loading this script!"). It worked, but it was error prone and manual.
More recent code has solved it by writing code that used abstract specifiers, like require('jquery'), which meant that you needed to use a complicated and often hyperconfigurable bundler to run in the browser (because the browser can't go searching the filesystem to figure out where the code for the 'jquery' package is)
With ES modules we're almost there, browsers can import files now, but they still need a bit of additional info to tell them how to resolve underspecified modules like 'jquery' (as opposed to './utils.js' which they can handle with no problem). You can write your code with fully specified imports, but the difficulty is that that code doesn't travel well, e.g. if you write `import '../node_modules/jquery/jquery.js'` that won't work if someone uses your package as a library, because jquery.js will actually be at '../jquery/jquery.js' because your package lives in the node_modules directory.
because literally just putting them in a folder somehow became insufficient for any number of reasons, some of which seem to have to do with JS's lack of an include() function like every other interpreted language has had since forever
like, how about i don't need 20,000 dependancies, and just use an application stack that includes normal things like trimming a string
This has been solved by ES Modules, which is already in all major browsers. Only IE is lagging behind (but there are polyfills).
By writing all code from scratch so that it doesn’t require any dependence’s from aging frameworks.
If everyone wrote their own kits then the web would be a more of a mature place.
Downvoted without any reasons? The web once before didn’t rely on frameworks.
PHPNuke wasn’t a framework.
PHPBB wasn’t a framework.
E107 wasn’t a framework.
If you wanted something. you coded it yourself.
/shrug
maybe it’s just me that feels the web is now polluted with Mb’s of wasted code. And even now it’s seen as bad practise not to use framework.
Hey now, let's not discount the rise and fall of NoSQL, reinventing of data analysis except using python and spark cause SQL is too boring, or discovering linear regressions using a fleet of GPUs under the banner of Machine Learning!
It'll be nice when people get back to solving real business problems.
- Use better JS (TypeScript) to be sent as ES5 (down to IE6 supoort) without waiting for people to upgrade their browsers to the latest, which is forever.
- Upgrade to latest specified version of libraries without having have to check every site and download the min.js or change the script tag url manually and dependencies are resolved automatically.
- Get to use stuff like stylus which is already far better than CSS 3 syntax and again, no need to wait for people to upgrade their browsers.
- Bundle all JS and CSS as a single file (and place all the other assets like images at a specified location automatically), which can be cached for instant load from second page, unless your frontend code is so fat, a single file becomes too huge for it.
- If your server side is node.js, you get to use a completely same language (TypeScript) for backend and frontend.
I've rescued several projects where more time was spent on making the lives of the developers "easier" than actually solving the problems of the user. Bike shedding and navel gazing is a huge problem in our industry, even if we don't like to admit it.
Also if your needs are simple you can just write a cgi script (provided you don't need too many RPS.)
Snowpack is for bundling ES modules to build web applications. Nothing mentioned in your comments works to build a client-side web application. If this your comment was some sly remark, it's totally lost on me.
Also, what's RPS?
It's basically just a static file server that can automatically rewrite bare module specifiers using Node module resolution. It's the minimal transform you can apply to npm-installed JS modules that import dependencies via package name.
Yes, you get a waterfall of loads during development, but I haven't had this slow things down in practice, and once you get to development you can use Rollup to bundle modules, but unlike Webpack, it can bundle to standard module output.
What about SASS, minification, etc?
But they're missing the point, this is a really good idea.
I used to use 1000 NPM packages as a sarcastic example about bad decisions and death by dependency overkill then I installed Angular which pulls in 1100 packages alone. The end user doesn’t care about your framework choice, favorite language, tech stack, or build process. They just know your application is slow, clumsy, and riddled with defects.
With web assembly maturing, interacting with this mess is becoming increasingly optional. Also languages like typescript and kotlin that compile to javascript add layers of much needed sanity. IMHO any project not using that is doing it wrong at this point. I'm very aware that this is opinionated and even offensive to some but after 2 decades of "maybe this will fix it" type innovation in the javascript world, I have very little patience left for that. The less I'm exposed to that smelly pile of manure, the better IMHO.
So, my recommendation: avoid this tool and use a sensible compile, verify, test, minify, and package it up style tool chain like all the grown ups do these days. I agree, tools for this are very much a cluster-fuck in terms of complexity, lack of any sane defaults that are actually good enough, usability, and performance but they're better than nothing.
In an ideal world, you'd not have to download hundreds of MB of layers of tools around tools that try to fix and work around each other. But there's no good technical reason to skip using them entirely. There's no sane excuse to skip sanity checks, type checks, static code analysis and running tests (and designing such that you can actually do this in a sane way, which seems to be hard with JS). Skipping that is immature and irresponsible. I don't tolerate it in my own projects and have no patience for self styled full stack js ninjas claiming their code is fine. It's not anywhere near fine.
Also, my guess is JS still predominates as the web language being used by developers, provided that React syntax is included.
I'm a core contributor on Rollup. Rollup is surging, and we've been seeing a ton of interest and new contributors. We're doing some awesome things to improve it, and if you'd like to help advance ES Modules and tooling, we'd love your help.
It's almost like comparing jQuery to web components, maybe you can achieve similar things to both, but one is a feature with native browser support.
> - Anyone who loves tooling-heavy development! This isn’t sarcastic, I promise! By dropping the bundler, you can’t do the magic that Webpack is famous for. Using import to load CSS, Images, and other non-JS resources is non-standard and unsupported in the browser (for now). You may appreciate a dev environment that is true to what standard JavaScript browsers support. Or, you may find this annoying.
---
I like that they make this a point, and I'm very much in the "let's not overload the standards" camp so I appreciate this as a feature, not a bug. This convinces me to give this tool a go!
Webpack certainly is confusing too. I did a side project with some webpack and es6 stuff. It was kinda fun, but man, front-end development has sucked forever. I remember back in the day having to fight with IE6. Here we are, thirteen fucking years later and shit seems to have gotten only MORE complex.
I look at server-side programming for comparison. PHP for instance certainly is more complex with some of the frameworks you can use now and of course composer. But those are WAY simpler than the shit I had to deal with when coding the front. I just don't understand how things have gotten more complex on the front-end, brutal.
It got me thinking about playing around with WebAssembly for building front-end applications. Maybe that doesn't fit all use-cases and maybe the grass is always greener, but I wonder if programming in sane ecosystem would be the sane thing to do...?
Put me in the camp that if there isn't a use-case slapping me in the face, choking me, and yelling at me to do a SPA then I'll avoid the shit like a plague. I'll just go with server-side render pages and sprinkle in some very basic jQuery as needed. I actually did that for a CRM two years ago and the thing is so damn simple to program in, because JavaScript is only used if it ACTUALLY provides a benefit to the user. There is a site-wide script that is maybe 100 lines of code. Then some page-specific things that load in stuff using RequireJS, but the most complex JS out of those is maybe 300 lines. The vast majority of the site doesn't really use much JavaScript. Just plain old MVC.
As always, please BURN YOUR JAVASCRIPT STICKERS.
I can’t count the number of times the solution to a problem we had was described as ‘just add these lines of magic to your webpack config’.
Really, setting up and fixing js tooling breakage often take more time than actual development for smaller projects