Fu**ing Webpack
-
I know this is probably me just showing my age, however all modern web development is virtually mandated to use one Javascript framework or other, whether it be React, Angular or perhaps Vue. This is all well and good, in that it's theoretically more efficient, and separates the concerns of presentation and business logic more clearly. Plus allows APIs to be reused for Mobile apps, and interoperability with other services.
This is all fantastic. Until you encounter Webpack. I don't really understand it's reason for existing other than to be a cryptic and esoteric minifier / obfuscator. Yeah, it promises to be "Awesome" and bundle your resources such that they are optimized for efficiency and handle parsing of every framework's unique method of crunching HTML, CSS and JavaScript together into single file, plus it promises to manage the dependency chain for you.
Except that it doesn't work; by that I mean that dependency management is one of the primary things it needs to do but the correct way of doing it (so that it consistently works) takes many magic stages spread over many unrelated plugins configured in the right way in the precise right order with the right versions of everything. And there is no guarantee that the stuff won't change completely next
yearmonthweek.Is there a "right" way of holding this thing if you don't want to use NodeJS as your webserver, and really only care about security updates, not the latest way someone has come up with to reinvent / change the wheels already availible when you started the project.
-
@idzy If you're using
npx create-react-app my-appand then, after having developed your site to your liking,buildthe whole thing you'll get a folder which only contains static files and is completely web server agnostic. Of course, you'll have to create a backend API (be that REST or Websocket or whathaveyou) but this way you're not bound to Node.But then, I'm not really sure what you're asking here for? Maybe clarify why you posted this in Coding Help?
-
@Rhywden It's not so much Node that I'm complaining about. I'm aware that Webpack creates static content that can be served by anything. However it manages to mangle a perfectly working Vue CLI app into something that no longer works after deployment, with obscure and impossible to debug / reproduce issues.
Admittedly, with literally hours of the familiar but agonizing cycle of google -> trial -> error -> cafinate -> repeat, it will spit out something that works.
But I'm just curious as to why people like it? Gulp and Grunt worked, and were much simpler. Webpack is over-complicated for what it is, and seems to get inextricably weaved into every project I've worked on in the last 12 months by some hipster zealot, who also refuses to help debug issues with it (giving some platitude answer like "just google it"), then always manages to leave the company just before crunch time.
-
@idzy I'm still not seeing the "Code Help" issue here, though.
-
@Rhywden I don't need help in so much as I have my own personal answer "Don't use it".
But depending on the project, I don't have that kind of authority. I was just wondering, if there is a pain free way to reliably deploy a fairly complex Vue app, backed by a well-written and comprehensive JSON API, as well as WebRTC + MPEG Dash or HLS (back-end is .NET Core, served by nginx via Unix Socket), with extensive use of Video.js, Leaflet and SignalR on the front end. All this works fine in Dev, but we have a constant stream of issues deploying with Webpack. the PM refuses to allow me to spend the day or so required to remove all the dependencies our code has on the deployment tool (which should have already set off alarm bells), on the grounds that it introduces unnecessary risk so late in the project (which I see the logic in, so don't blame him for the decision). Just wondering if there is anyone with deep experience in this area who can give me a magic bullet answer.
-
@Rhywden Unless "Code Help" is a euphemism for something other than asking serious questions of other developers, I thought someone may have some deep knowledge of this tool or even just point me to some useful documentation. The main issue I have is probably more project specific, as the guy who initially configured Webpack did so with a bunch of unnecessary complexity, such that it mixes 3rd party library code with our own JS code. I'm just frustrated and needed to vent. Working almost alone over the holidays is bad enough, and spending my time dealing with this bullsh*t isn't what I'm even meant to be doing.
Sorry if it's in the wrong place. It's neither amusing, nor really a WTF.
Believe me, I've already exhausted Stack Overflow, the Vue.js forums and the Webpack Github. I'll figure it out, I'm just pissed off that I could (and arguably should) be at home enjoying some sleep.
-
@idzy said in Fu**ing Webpack:
Sorry if it's in the wrong place. It's neither amusing, nor really a WTF.
Oh, this is the right place if you want a recommendation or answer to a clear question. The point is though that you might need to highlight what you want to talk about, because ranting and complaining is what the rest of the forum is for.
I'm not able to help though, as a backend dev who is allowed to work with C# I stay well away from anything JavaScript related...
-
@JBert The full question would take an essay to describe. So here probably isn't the best forum for it. Sorry all.
I'm a full-stack dev, but find back-end work far more rewarding. This is the first commercial project I've worked on which uses .NET Core on Linux, and I'm absolutely loving it (after 25 years in the industry, it takes a lot to excite me). Even more fun is it's PostgreSQL Entity Framework driver, which is one of the best tools I've ever used. It manages to take advantage of the Object-Oriented features of PostgreSQL, whilst providing a water-tight abstraction, in that your model code is not polluted with artefacts to make this possible.
Overall, the whole thing has been a really fun project, and for once I really must commend Microsoft for going all in on their Open Source initiatives. VS Code finally convinced me to ditch vim (I'm gonna miss my .vimrc file which took years to perfect), and .NET Core seems to be more performant than the JVM, so it's looking like a bright future for back-end developers.
-
@idzy for .net devs, we generally find core to not work as well as the previously main framework, so it amuses me that it's better than what you've been dealing with. It's been improving rapidly, though. The next thing you should look at if you like that is blazor though: you just kick the rest of the js out the window with that thing.
-
@idzy said in Fu**ing Webpack:
I thought someone may have some deep knowledge of this tool
I might have time later to read through this thread and offer help, if I can fend off the warthog.
-
@Magus said in Fu**ing Webpack:
The next thing you should look at if you like that is blazor though: you just kick the rest of the js out the window with that thing.
I'm already playing with it at home. It'll take a while for me to convince someone to let me use it on a commercial project though, but Wasm in general is an awesome step forward for the web. Finally we can stop using (or transpiling) to a hack-job of a language which everyone admits is fundamentally broken.
for .net devs, we generally find core to not work as well as the previously main framework
Compared to the JVM on Linux, it's simpler, faster, easier to deploy, and (touch wood) has not given us any stability issues as of 3.1. Running it behind nginx significantly mitigates a lot of potential security vulnerabilities in a new webserver.
Compared to dynamically typed languages like Python, PHP, Ruby, etc. C# is much better suited to back-end development, and the .NET Core version of EF seems to lose a lot of baggage / tech-debt that the standard framework version still carries (presumably for backward compatibility reasons). Best of all, you can still use the full-blown Windows Visual Studio IDE as your main development environment (despite what anyone says, warts and all, it's still the best IDE on the planet).
I don't really agree that Core is inferior to the standard framework (and am still unsure as to why they forked the windows version of the runtime into ".NET Standard" and ".NET Framework"). But despite Core's standard library being a bit minimalist, what they've removed are often no longer best practices to use or rendered obsolete by Linq & functional style programming which is now really well supported.
Even though Mono has existed for ages, you Windows guys have had a practical monopoly on what is arguably the most aesthetically pleasing and productive general purpose language there is (C#) for too long ;)
-
Skimming the thread from the gym; it sounds like you got the wrong elevator pitch.
Webpack, like many tools, doesn't do amazing things on its own. It, rather, can be used to do amazing things, if you're willing to put forth the effort to learn to use it well.
-
Example of amazing things being done with webpack: I use webpack's Hot Module Replacement feature to patch new features into @error_bot while it's running.
I save a code file, and it gets transpiled and injected into the running application in under 300ms with virtually no downtime.
I've made bug fixes and added features to games while people were actually playing the game.
(HMR doesn't "just work" though. It took a lot of work to get it working.)
-
@error said in Fu**ing Webpack:
Webpack, like many tools, doesn't do amazing things on its own.
That's the point. I don't want, nor do I need it to do amazing things. I really just need it to convert .vue files into something which can used by a webserver. Nothing more, Nothing less. There are plenty of other minifiers & packaging tools that do what I want without needing to become deeply involved in yet another an ever-changing ecosystem filled with erratic and pointless changes on a regular basis.
-
@idzy Sounds like the wrong tool for your needs.
-
@error I completely agree. Changes to this app will never be deployed without going through extensive QA, and upgrades done on cold VMs, with the load balancer being reconfigured to point to the updated servers after verification.
-
@idzy said in Fu**ing Webpack:
I don't really agree that Core is inferior to the standard framework (and am still unsure as to why they forked the windows version of the runtime into ".NET Standard" and ".NET Framework").
.NET Framework is the Windows runtime. .NET Standard is just a spec. (Specifically, the lowest common denominator between .NET Framework, .NET Core, and other .NET runtimes. A DLL can be targeted to .NET Standard and be guaranteed to run on pretty much any .NET runtime.)
If you're asking why they forked .NET Framework into .NET Core instead of just releasing a cross-platform version: too much platform-specific stuff was embedded into the .NET Framework. Forking let them have a clean break.
-
-
@Unperverted-Vixen said in Fu**ing Webpack:
.NET Framework is the Windows runtime. .NET Standard is just a spec.
Thank heaps for that bit of info.
I fully understand the reasons behind .NET Core, and why it was necessary to change the CLR, JIT and Standard Library for cross platform support. As a predominantly Linux developer, I'm genuinely excited to have a supported C# implementation to work with.
-
@Unperverted-Vixen said in Fu**ing Webpack:
.NET Framework is the Windows runtime. .NET Standard is just a spec. (Specifically, the lowest common denominator between .NET Framework, .NET Core, and other .NET runtimes. A DLL can be targeted to .NET Standard and be guaranteed to run on pretty much any .NET runtime.)
This was true up until recently, when they declined to have .NET Framework move forward on the Standard track because it included a few features that required CLR-level changes that the decision-makers were afraid to push into Framework for fear of breaking something for someone somewhere.
-
@Mason_Wheeler True. Practically speaking, I don’t expect to see .NET Standard 2.1 get any actual use in the wild. Library authors who want to support Framework have to stay on 2.0, while authors who don’t care are better off targeting .NET Core directly to get new features faster.
-
@Unperverted-Vixen ...maybe. I'm not so sure. The signaling we've been hearing out of Microsoft recently has been pretty clear: Framework is now deprecated in all but name; Core is the future and the way forward.
-
@Mason_Wheeler I agree regarding the death of Framework. But if I’m writing a library, I’d rather target Core 3.x and get access to new shinies as they’re introduced than Standard 2.1.
-
@Unperverted-Vixen Fair enough...
Also known as a standard.