Webpack 4 course: What is Webpack?(wanago.io)
wanago.io
Webpack 4 course: What is Webpack?
https://wanago.io/2018/07/16/webpack-4-course-part-one-entry-output-and-es6-modules/
66 comments
It's a common pattern in JS to use many small packages over fewer large ones. Some maintainers might take this too far, breaking their package up so that each function gets its own package. That is how you get 388 dependencies in complex packages.
A vanilla install of Phoenix with Brunch yields a node_modules with 388 packages
Look at what Phoenix (https://hexdocs.pm/phoenix/overview.html) and Brunch (https://brunch.io/) can do. To suggest 388 packages for all that stuff is too much is ridiculous - there's a lot of functionality, so there's a lot of code. The fact that it's not one huge, opaque blob is a good thing. Could they be implemented with less code? Maybe. Does that mean they'd be better for it? I don't think I've ever come across a reasonable argument that says 'less code is always better'.
You could very reasonably argue that you don't need all those features, and maybe the two things are bloated. I would suggest that means you've picked two things that do way more than you need, and you've not chosen your tech stack very well.
Look at what Phoenix (https://hexdocs.pm/phoenix/overview.html) and Brunch (https://brunch.io/) can do. To suggest 388 packages for all that stuff is too much is ridiculous - there's a lot of functionality, so there's a lot of code. The fact that it's not one huge, opaque blob is a good thing. Could they be implemented with less code? Maybe. Does that mean they'd be better for it? I don't think I've ever come across a reasonable argument that says 'less code is always better'.
You could very reasonably argue that you don't need all those features, and maybe the two things are bloated. I would suggest that means you've picked two things that do way more than you need, and you've not chosen your tech stack very well.
Look at all what django does.
It has one dependancy.
No, there are 2 reasons for this dependency creep:
- the fact JS has a so few features and such a little stdlib. So everyone has to rewrite even basic stuff.
- the community culture toward stability, maintenance and future proofing is almost inexistent in JS.
Too many JS devs have only ever coded in JS. This give them have a very twisted, unbalanced view of programming.
It has one dependancy.
No, there are 2 reasons for this dependency creep:
- the fact JS has a so few features and such a little stdlib. So everyone has to rewrite even basic stuff.
- the community culture toward stability, maintenance and future proofing is almost inexistent in JS.
Too many JS devs have only ever coded in JS. This give them have a very twisted, unbalanced view of programming.
Phoenix is actually very agnostic as far as asset packaging goes, one can swap Brunch for Webpack or Parcel (or nothing) easily. So it's not to say those 300+ build-time-only node packages have anything to do with Phoenix (or Elixir, or Erlang's) ability.
there are many reasons while less code is better -- https://blog.codinghorror.com/the-best-code-is-no-code-at-al...
"very new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity."
More code, more bugs, more issues. 388 packages is ridiculous compared to practically every major system including operating systems. Javascript is Stockholm syndrome.
"very new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity."
More code, more bugs, more issues. 388 packages is ridiculous compared to practically every major system including operating systems. Javascript is Stockholm syndrome.
Using packages means less code, not more, since you're not rewriting the wheel every time.
Technically not if packages are just the misguided habit of "one package per function" seen in the Node ecosystem. Same amount of code, increased amount of complexity/meta-problems to deal with.
> Technically not if packages are just the misguided habit of "one package per function" seen in the Node ecosystem.
No. Using a package for a single function doesn't preclude code reuse.
Look at underscore.get package. You could write your own recursive key finder (which I have before), and so could every package author, and you'd have 10x the amount of implementations of a recursive key finder.
A single require of underscore.get by you and other authors means you have a single, well tested implementation with a million other users rather than 10 low quality ones.
No. Using a package for a single function doesn't preclude code reuse.
Look at underscore.get package. You could write your own recursive key finder (which I have before), and so could every package author, and you'd have 10x the amount of implementations of a recursive key finder.
A single require of underscore.get by you and other authors means you have a single, well tested implementation with a million other users rather than 10 low quality ones.
Why not one package per line of code? One package per expression? Surely, someone will want to reuse var x = a + b.
[1] https://github.com/NarHakobyan/underscore.get
const {get} = require("underscore.get");
get(obj, 'a[0].b', defaultValue);
[1] https://github.com/NarHakobyan/underscore.get
> Why not one package per line of code?
Exactly. If it's a difficult line of code, with edge cases, requiring unit tests, etc. then sure. Algorithms are a great example of this.
Using your own example: how many badly written copies of https://github.com/NarHakobyan/underscore.get/blob/master/un... do you want?
Exactly. If it's a difficult line of code, with edge cases, requiring unit tests, etc. then sure. Algorithms are a great example of this.
Using your own example: how many badly written copies of https://github.com/NarHakobyan/underscore.get/blob/master/un... do you want?
What is Webpack?
A several horrific hours of googling how to fix its configs so that it just works
A several horrific hours of googling how to fix its configs so that it just works
I hear this trope here a lot, always seems to gloss over what webpack improved on, which is replacing bespoke build scripts for web projects. Also that it greatly reduced the ye olde tradition of coding to the least common denominator subset of features that runs on all browsers. Webpack was and is awesome for that.
> coding to the least common denominator subset of features that runs on all browsers
Did Webpack do that or did Babel?
Did Webpack do that or did Babel?
Babel. Webpack is just a glue. An over complicated glue.
> replacing bespoke build scripts for web projects
Does it, though? No project of moderate complexity will be able to reuse a Webpack config. Conversely, how large of a problem was this for simple sites?
Does it, though? No project of moderate complexity will be able to reuse a Webpack config. Conversely, how large of a problem was this for simple sites?
I still use shell scripts for moving assets around and build sass, I use webpack for the TypeScript/dependency managment (via yarn).
I looked at doing it with webpack but frankly 2 lines of bash that'll work the same in a decade vs haha no wasn't a hard choice.
I looked at doing it with webpack but frankly 2 lines of bash that'll work the same in a decade vs haha no wasn't a hard choice.
The fact having a broken arm is better than having aids doesn't mean breaking an arm is nice.
What is Webpack?
A question you’ll find yourself Googling every month as the “best approaches” change.
A question you’ll find yourself Googling every month as the “best approaches” change.
I have spent many hours on many versions of WebPack for code that has gone to production for a large company. I cannot give any more detail than that.
WebPack 1.x was very powerful but very difficult to understand and configure. There weren’t a lot of sane defaults and the docs did very little to adequately explain the core concepts. The problem(s) WebPack wolves are pretty complex and I haven’t seen anything else do quite what it does.
Starting with 2.x, the docs are great. They explain the concepts pretty well. They give you basic setups and examples throughout. 2+ also has a simplified base config: you only need a few items in your config to start getting some pretty big benefits.
While WebPack was not the first and certainly isn’t the only tool that provides what it does, it does provide a sort of one stop shop for a lot of what used to be separate tools. I don’t feel like it locks me in however.
Along with the ability to minify and other such “utility” functions (which you don’t have to do with WebPack), you get things like tree shaking. This can drastically shrink your final bundle.
As someone who does a lot of UI development, it’s also nice to be able to use ES2015 features like import without having to worry.
tl;dr I see complaints about WebPack being complicated and config heavy. It used (1.x) to be exactly that. It’s much better and the benefits from using it far beyond worth the (now little) upfront learning IMO.
WebPack 1.x was very powerful but very difficult to understand and configure. There weren’t a lot of sane defaults and the docs did very little to adequately explain the core concepts. The problem(s) WebPack wolves are pretty complex and I haven’t seen anything else do quite what it does.
Starting with 2.x, the docs are great. They explain the concepts pretty well. They give you basic setups and examples throughout. 2+ also has a simplified base config: you only need a few items in your config to start getting some pretty big benefits.
While WebPack was not the first and certainly isn’t the only tool that provides what it does, it does provide a sort of one stop shop for a lot of what used to be separate tools. I don’t feel like it locks me in however.
Along with the ability to minify and other such “utility” functions (which you don’t have to do with WebPack), you get things like tree shaking. This can drastically shrink your final bundle.
As someone who does a lot of UI development, it’s also nice to be able to use ES2015 features like import without having to worry.
tl;dr I see complaints about WebPack being complicated and config heavy. It used (1.x) to be exactly that. It’s much better and the benefits from using it far beyond worth the (now little) upfront learning IMO.
Something that should be avoided unless you really need it
it shouldn't be config based, should be a DSL or a library that's verbose enough to understand the workings of.
Interesting that you should mention it. This talk https://www.youtube.com/watch?v=mVVNJKv9esE mentions some arguments why a DSL would not be a good approach for frontend/JS build tools. Namely that a DSL isn't adequate if the underlying best practices or requirements change a lot. That's why operating at a higher level of abstraction (function chaining/piping/composition) would make more sense.
Now... that doesn't really favor Webpack. And I still don't quite understand why that tool is so popular.
Now... that doesn't really favor Webpack. And I still don't quite understand why that tool is so popular.
> That's why operating at a higher level of abstraction (function chaining/piping/composition) would make more sense.
That's just back to Gulp.
That's just back to Gulp.
For those intimidated by the webpack config you should check parcel : https://parceljs.org/
ParcelJS was great before Webpack 4, but now Webpack has a very good zero config mode you don't really need ParcelJS. It's still nice though.
Zero config offer only limited features. And if you want to add any one more, you are back to conf everything from scratch, including the zero conf stuff.
create-react-app and vue-cli and much better designed in that regard. And yet they are using webpack.
External projects manage to be better at webpack than the webpack team.
create-react-app and vue-cli and much better designed in that regard. And yet they are using webpack.
External projects manage to be better at webpack than the webpack team.
And it's an accident that could have been prevented.
The JS ecosystem looks like an isolated entity that contracted amnesia and a learning disability. It then proceeded to remake every single mistake done in 30 years of prior art, while ignoring every other communities warning again and again about it.
And to add insult to injury, devs from the community answered that everything was fine, and that it was us who didn't understand, and failed to live in modern times.
It's getting better. But it took a while because so many JS devs have only ever coded in JS, giving them an incomplete and crooked big picture.
The JS ecosystem looks like an isolated entity that contracted amnesia and a learning disability. It then proceeded to remake every single mistake done in 30 years of prior art, while ignoring every other communities warning again and again about it.
And to add insult to injury, devs from the community answered that everything was fine, and that it was us who didn't understand, and failed to live in modern times.
It's getting better. But it took a while because so many JS devs have only ever coded in JS, giving them an incomplete and crooked big picture.
If you think Webpack is solving an easy problem, you don't understand the problem.
I do not think so. And I think Webpack actually clearly shows the way where JS ecosystem goes – creating one layer of complexity on top of another. Each new layer, of course, solves the problem (not an easy one) of the previous one, but creates new problems, that will be resolved by the next layer.
Essential complexity in this case is just a need to run a code. That's it. I just want to run one command, with one or two switches max, and get the result running in a browser.
Accidental complexity is when you have a tool that 99% of developers couldn't quickly grasp and need to spend many hours studying courses or reading books (!) on Webpack.
Someone should stop this madness.
Back in 1975 (43 years ago!) Tony Hoare said:
"The pursuit of complexity is easy... But the pursuit of simplicity is one of the most difficult and challenging activities of the human mind. Progress is likely to be extremely slow, where each complexity eliminated must be hailed as a breakthrough. We need not only brilliance of intellect but breadth of experience, nicety of judgement, excellence of taste, and even more than our fair share of good luck. And finally we need a puritanical rejection of the temptations of features and facilities, and a passionate devotion to the principles of purity, simplicity and elegance."
Essential complexity in this case is just a need to run a code. That's it. I just want to run one command, with one or two switches max, and get the result running in a browser.
Accidental complexity is when you have a tool that 99% of developers couldn't quickly grasp and need to spend many hours studying courses or reading books (!) on Webpack.
Someone should stop this madness.
Back in 1975 (43 years ago!) Tony Hoare said:
"The pursuit of complexity is easy... But the pursuit of simplicity is one of the most difficult and challenging activities of the human mind. Progress is likely to be extremely slow, where each complexity eliminated must be hailed as a breakthrough. We need not only brilliance of intellect but breadth of experience, nicety of judgement, excellence of taste, and even more than our fair share of good luck. And finally we need a puritanical rejection of the temptations of features and facilities, and a passionate devotion to the principles of purity, simplicity and elegance."
Front-end developers want more than to just run code, though. We want to be able to use modern JS and CSS without worry. We want live-reloading of styles. We want to minify and clean up our code, and to break it into smaller chunks. We want code-linting to keep ourselves and others in check.
All of those things I see as being essential to building quality code in a reasonable amount of time (and enjoying it), and all of those things are actually really easy to set up in Webpack (it's all in their docs). Webpack was overwhelming before I read through their docs, and their docs are not as nice as VueJS's docs, but it isn't as bad as everybody makes it out to be. Really.
All of those things I see as being essential to building quality code in a reasonable amount of time (and enjoying it), and all of those things are actually really easy to set up in Webpack (it's all in their docs). Webpack was overwhelming before I read through their docs, and their docs are not as nice as VueJS's docs, but it isn't as bad as everybody makes it out to be. Really.
You're right, web development is more than just run a code, but it's not an order of magnitude more. If you use sane defaults, find the most common patterns and workflows, identify trade-offs and come up with elegant conventions, you'll be able to hide the complexity and make it simple for people to learn, grasp, use and, consequently, to contribute and improve. But simplicity is complicated and it's way more easier to do a feature-rich extra-configurable monster and write books on how to use it.
As for the "reasonable" part – it's extremely subjective and we all should account our judgements for that. Back in 2005 I was OK with the fact that I need to go for the coffee break when I start compiling a C++ program. If you'd asked me "do you think C++ compilation time is slow" those days, I would reply "absolutely not" and find explanations why it's reasonable. Now, after Google couldn't stand C++'s complexity and compilation times and created Go language with its subsecond compilation times, my understanding of reasonable has shifted dramatically. It's just doesn't make sense anymore to compile something more than 10 seconds, and 15 mins compilation times are now in a "madness" bucket.
As for the "reasonable" part – it's extremely subjective and we all should account our judgements for that. Back in 2005 I was OK with the fact that I need to go for the coffee break when I start compiling a C++ program. If you'd asked me "do you think C++ compilation time is slow" those days, I would reply "absolutely not" and find explanations why it's reasonable. Now, after Google couldn't stand C++'s complexity and compilation times and created Go language with its subsecond compilation times, my understanding of reasonable has shifted dramatically. It's just doesn't make sense anymore to compile something more than 10 seconds, and 15 mins compilation times are now in a "madness" bucket.
Shouldn't an IDE be able to do most of this?
> Essential complexity in this case is just a need to run a code. That's it. I just want to run one command, with one or two switches max, and get the result running in a browser.
So, why don't you just double click your index.html? Or is there more to the problem statement?
So, why don't you just double click your index.html? Or is there more to the problem statement?
> So, why don't you just double click your index.html?
Oh, believe me, whenever it's possible I do exactly this. If I have a chance to avoid bringing 100500+ new overcomplicated tools from JS world just to be able to run small WebGL project, I do.
Oh, believe me, whenever it's possible I do exactly this. If I have a chance to avoid bringing 100500+ new overcomplicated tools from JS world just to be able to run small WebGL project, I do.
> I do not think so. And I think Webpack actually clearly shows the way where JS ecosystem goes – creating one layer of complexity on top of another. Each new layer, of course, solves the problem (not an easy one) of the previous one, but creates new problems, that will be resolved by the next layer.
If there ever a need for red blinky text that quote is it. That is exactly what is happening. And JS fan boys get pissed about it when you point at it.
If there ever a need for red blinky text that quote is it. That is exactly what is happening. And JS fan boys get pissed about it when you point at it.
Web developers get pissed because its a strawman. Nobody uses the layers of complexity needed to preprocess, compile, load, link and finally run C++ as a fundamental criticism. Everything anybody does when they work on modern programming platforms is stand on top of layers of complexity that would make anyone's head spin. But when you're writing code for a living what matters is the quality of your hand-tools, the quality of the open source code you rely on and the expressiveness of your language and thus your ability to ship products. Modern web-dev and JS-dev has no problems in this area, but hey what do I know I've only been doing it for 14 years. My day is spent working on products and features, not fighting the language or tooling. Just like anything it requires a little effort and experience.
Exactly this. I sometimes work on projects without all nice tools that I'm used to using, and it works out just fine. I wouldn't choose or suggest to start a new project that way, though.
Reading through Webpack's docs one night was all I needed to start creating my own configs, and I improved upon that config as time went on. It was worth the investment in time.
Reading through Webpack's docs one night was all I needed to start creating my own configs, and I improved upon that config as time went on. It was worth the investment in time.
You are comparing C++, a bare metal language, to JS, a high level dynamic language running in the richest plateform ever created.
So what you are saying is that it's logical that the JS restaurant is hard to eat in, because for cooking you need to sharpen knife and chose the best fruits from the market.
To me, it's madness or dishonest.
My experience is that in JS it's usually both.
So what you are saying is that it's logical that the JS restaurant is hard to eat in, because for cooking you need to sharpen knife and chose the best fruits from the market.
To me, it's madness or dishonest.
My experience is that in JS it's usually both.
You sound like you haven't really had to do much real-world work in JS or C++.
Apart from managing memory, what makes C++ complicated is accounting for the differences between OSes and shared libraries and even different hardware capabilities.
But it's perfectly acceptable for many C++ developers to write code that only works on a single OS or to ship massive bundles that include various compatibility layers or specific versions of libraries to escape the hell that is dynamic library loading.
Developing rich applications (i.e. the kind of app that serves the same need as a desktop application you need to download and install) is similar, except it's rarely acceptable to say "oh, this web app only works in Safari" while it's often perfectly acceptable to say "oh, this desktop app only works on the latest macOS".
Instead of different OSes you have to deal with different browsers. Instead of shared libraries you have to deal with different implementation levels of web standards (which is rarely an "on or off" distinction but in practice often means having to deal with experimental prefixes, different draft stages and subtle differences with no easy way to determine in advance what the browser supports exactly). And you don't get to compile per platform and users will complain if your code bundle is too big or features aren't supported in their browser.
"But web sites are simpler" you might argue, but that's not webpack is used for. Or at least the web sites you'd complain aren't using it. A wordpress blog with tens of JavaScript files is the opposite of what you get when using a tool like webpack.
Ironically a simple blog with the same user-facing functionality would likely be much smaller and faster if built with webpack (because a lot of the redundancy and size stems from the good old days' "bolt-on" mentality which is still a common practice for web sites). But surprisingly enough that's not what webpack is used for because "everybody knows" it would be overengineering.
Apart from managing memory, what makes C++ complicated is accounting for the differences between OSes and shared libraries and even different hardware capabilities.
But it's perfectly acceptable for many C++ developers to write code that only works on a single OS or to ship massive bundles that include various compatibility layers or specific versions of libraries to escape the hell that is dynamic library loading.
Developing rich applications (i.e. the kind of app that serves the same need as a desktop application you need to download and install) is similar, except it's rarely acceptable to say "oh, this web app only works in Safari" while it's often perfectly acceptable to say "oh, this desktop app only works on the latest macOS".
Instead of different OSes you have to deal with different browsers. Instead of shared libraries you have to deal with different implementation levels of web standards (which is rarely an "on or off" distinction but in practice often means having to deal with experimental prefixes, different draft stages and subtle differences with no easy way to determine in advance what the browser supports exactly). And you don't get to compile per platform and users will complain if your code bundle is too big or features aren't supported in their browser.
"But web sites are simpler" you might argue, but that's not webpack is used for. Or at least the web sites you'd complain aren't using it. A wordpress blog with tens of JavaScript files is the opposite of what you get when using a tool like webpack.
Ironically a simple blog with the same user-facing functionality would likely be much smaller and faster if built with webpack (because a lot of the redundancy and size stems from the good old days' "bolt-on" mentality which is still a common practice for web sites). But surprisingly enough that's not what webpack is used for because "everybody knows" it would be overengineering.
> Nobody uses the layers of complexity needed to preprocess, compile, load, link and finally run C++ as a fundamental criticism.
I do. C++ is an excellent example of accidental complexity got out of control. Actually, C++ complexity has been a main reason of why Google created Go. And Go embraced pursuit of minimizing accidental complexity at its best.
> Modern web-dev and JS-dev has no problems in this area, but hey what do I know I've only been doing it for 14 years.
Number of years in industry is clearly not an a argument. It's actually may work against you. For example, I can assume that you can't see "problems in this area" because you spent years deep inside them, learning workarounds and solutions. So what a newcomer would call a "weird and complex" you may call "normal and obvious". (just an example)
I do. C++ is an excellent example of accidental complexity got out of control. Actually, C++ complexity has been a main reason of why Google created Go. And Go embraced pursuit of minimizing accidental complexity at its best.
> Modern web-dev and JS-dev has no problems in this area, but hey what do I know I've only been doing it for 14 years.
Number of years in industry is clearly not an a argument. It's actually may work against you. For example, I can assume that you can't see "problems in this area" because you spent years deep inside them, learning workarounds and solutions. So what a newcomer would call a "weird and complex" you may call "normal and obvious". (just an example)
> I do. C++ is an excellent example of accidental complexity got out of control. Actually, C++ complexity has been a main reason of why Google created Go. And Go embraced pursuit of minimizing accidental complexity at its best.
Fair enough, but every HN thread about C++ isn't flooded with non-C++ devs crawling out the woodwork to complain about it being too complicated from a position of ignorance.
I've been working in and out of the web industry for 14 years. Until 2014 I was a Adobe Flash designer. I learned modern JS and web development in 2014, before that I had never written a line of JS or CSS commercially, and never opened a unix shell - it took me half a year or so of effort while working other freelance gigs. Other devs that complain about it are either are ignorant, or not willing to put in the required effort to learn something worthwhile.
Fair enough, but every HN thread about C++ isn't flooded with non-C++ devs crawling out the woodwork to complain about it being too complicated from a position of ignorance.
I've been working in and out of the web industry for 14 years. Until 2014 I was a Adobe Flash designer. I learned modern JS and web development in 2014, before that I had never written a line of JS or CSS commercially, and never opened a unix shell - it took me half a year or so of effort while working other freelance gigs. Other devs that complain about it are either are ignorant, or not willing to put in the required effort to learn something worthwhile.
> but every HN thread about C++ isn't flooded with non-C++ devs crawling out the woodwork
The main difference between C++ and JS here, is that web has become a dominant platform. If you need to write anything that human should interact with, you're unlikely to build Desktop app, you'll go to the web – simply because it's a way to reach way more people. And by the twist of historic events it happened that the only programming language you can write it is something barely resembling real programming languages, something that has never been properly designed and thought of.
This actually feels like you're being forced to use JS without your consent, and that's where opportunity cost-like things start to happen. You know how effective you could be in a properly designed language and ecosystem, and when you spend hours fighting `function is undefined at index.js:2342342` bugs, and follow outdated tutorials just to realize that they are not working anymore, you know how much easier it would be if you had a choice in programming language, and you start hate it quite passionately.
> Other devs that complain about it are either are ignorant, or not willing to put in the required effort to learn something worthwhile.
I would not say so. I'm not a frontend dev, but I have 15+ years practical experience and can switch 2-3 languages almost daily. Right tool for the right job. While my main focus is server software, I like doing software with UI and was extremely happy in the early 2000-s doing this with C++/QT, and later developing Nokia N900 apps with Python and QML. That was just a great experience, and the learning path was logical and ecosystem is solid, so you can reuse what you've learned and advance this way.
Then around 2009 it become obvious that for apps with UI you need web. And I happily invested into learning how to do things. I was writing backends in PHP, then in Go, and for frontend I used jQuery, then Angular 1, then Angular 2 and React.
Backend part always took me around 5% of time, and 95% was frontend. From those 95% most time has been spent on trying to find logic in proposed solutions for the very basic things, and fighting with tooling and versions mismatches. Like, really, the real coding – i.e. solving "essential complexity" – was taking a tiny share of my time, but fighting with tooling, multiple approaches and solutions, that contradict each others, dynamic type absense errors, and simple stupid design desicions that made it to the mainstream was taking most of my time.
Needless to say, when I had to return to my projects in half a year, it just doesn't worked anymore, because ecosystem changed, tooling updated and become incompatible, and you find yourself trying to rewrite code to match newer versions. And it seems to be common thing in JS world – people just break APIs and libraries for almost no reason (`Button.Raised` -> `RaisedButton`, really?) and they fine with it. There is a whole mentality of "breaking API is totally OK" and a second generation of developers sees nothing bad in it. And, of course, you can't find anyone to help you, because that framework is already considered outdated and nobody wants to touch it.
So no, it's not an ignorance, it's merely respect of your time and mental health, and not accepting that you a) have no choice and should embrace technology no matter how bad it is b) your knowledge you're invested into will be outdated in half a year.
The main difference between C++ and JS here, is that web has become a dominant platform. If you need to write anything that human should interact with, you're unlikely to build Desktop app, you'll go to the web – simply because it's a way to reach way more people. And by the twist of historic events it happened that the only programming language you can write it is something barely resembling real programming languages, something that has never been properly designed and thought of.
This actually feels like you're being forced to use JS without your consent, and that's where opportunity cost-like things start to happen. You know how effective you could be in a properly designed language and ecosystem, and when you spend hours fighting `function is undefined at index.js:2342342` bugs, and follow outdated tutorials just to realize that they are not working anymore, you know how much easier it would be if you had a choice in programming language, and you start hate it quite passionately.
> Other devs that complain about it are either are ignorant, or not willing to put in the required effort to learn something worthwhile.
I would not say so. I'm not a frontend dev, but I have 15+ years practical experience and can switch 2-3 languages almost daily. Right tool for the right job. While my main focus is server software, I like doing software with UI and was extremely happy in the early 2000-s doing this with C++/QT, and later developing Nokia N900 apps with Python and QML. That was just a great experience, and the learning path was logical and ecosystem is solid, so you can reuse what you've learned and advance this way.
Then around 2009 it become obvious that for apps with UI you need web. And I happily invested into learning how to do things. I was writing backends in PHP, then in Go, and for frontend I used jQuery, then Angular 1, then Angular 2 and React.
Backend part always took me around 5% of time, and 95% was frontend. From those 95% most time has been spent on trying to find logic in proposed solutions for the very basic things, and fighting with tooling and versions mismatches. Like, really, the real coding – i.e. solving "essential complexity" – was taking a tiny share of my time, but fighting with tooling, multiple approaches and solutions, that contradict each others, dynamic type absense errors, and simple stupid design desicions that made it to the mainstream was taking most of my time.
Needless to say, when I had to return to my projects in half a year, it just doesn't worked anymore, because ecosystem changed, tooling updated and become incompatible, and you find yourself trying to rewrite code to match newer versions. And it seems to be common thing in JS world – people just break APIs and libraries for almost no reason (`Button.Raised` -> `RaisedButton`, really?) and they fine with it. There is a whole mentality of "breaking API is totally OK" and a second generation of developers sees nothing bad in it. And, of course, you can't find anyone to help you, because that framework is already considered outdated and nobody wants to touch it.
So no, it's not an ignorance, it's merely respect of your time and mental health, and not accepting that you a) have no choice and should embrace technology no matter how bad it is b) your knowledge you're invested into will be outdated in half a year.
I hear you, your criticisms are valid but you've identified the wrong cause. It's not the tooling, or languages themselves, rather the web platform.
With the web platform everything is sat on top of shifting sand ... i.e. changing browsers, standards and devices. Almost nothing in the tech world has changed so fast over the last 15 years than the software and devices web platform code is expected to run on. I'd say that given that churn, the quality of modern web languages and tooling is remarkable.
Writing backends vs frontends is a totally different thing. Backends tend to run in stable environments, and mainly you concern yourself with data in and data out. That's not to say its easy, there can certainly be be plenty of "essential complexity", and infrastructure and scaling is a whole additional set of concerns. Frontend by contrast is a much more fuzzy issue, clients need to run across many unstable environments and require skills very far from traditional programming - sensitivity to design, UX and animation for example. If you're good at backend, it doesn't mean you're going to enjoy frontend too. And if you don't enjoy frontend it doesn't mean all the frontend tech is "bad".
With the web platform everything is sat on top of shifting sand ... i.e. changing browsers, standards and devices. Almost nothing in the tech world has changed so fast over the last 15 years than the software and devices web platform code is expected to run on. I'd say that given that churn, the quality of modern web languages and tooling is remarkable.
Writing backends vs frontends is a totally different thing. Backends tend to run in stable environments, and mainly you concern yourself with data in and data out. That's not to say its easy, there can certainly be be plenty of "essential complexity", and infrastructure and scaling is a whole additional set of concerns. Frontend by contrast is a much more fuzzy issue, clients need to run across many unstable environments and require skills very far from traditional programming - sensitivity to design, UX and animation for example. If you're good at backend, it doesn't mean you're going to enjoy frontend too. And if you don't enjoy frontend it doesn't mean all the frontend tech is "bad".
Babel is solving a complex problem.
Webpack is not.
Webpack is basically a task runner, a bungler and a configuration system. It relies on plugins to do anything hard.
The fact it's breaking compat again is so few years itself is alarming.
But it's crazy that a tool that only glues things together is still unable to provide a better API that it currently is.
Webpack is not.
Webpack is basically a task runner, a bungler and a configuration system. It relies on plugins to do anything hard.
The fact it's breaking compat again is so few years itself is alarming.
But it's crazy that a tool that only glues things together is still unable to provide a better API that it currently is.
Do you have an better alternative? I haven't seen other tools which have a community this large, do automatic bundling and can handle (through plugins) all kinds of inputs. But that may just be my ignorance.
There is a reason we use this terrible tool: it's the only one that does everything it does.
That doesn't make it good.
It's like JS itself: it's a horrible language, but it's the only one that runs natively all popular web browsers.
When you have a monopoly, you don't need to be good. You just need to be here.
That doesn't make it good.
It's like JS itself: it's a horrible language, but it's the only one that runs natively all popular web browsers.
When you have a monopoly, you don't need to be good. You just need to be here.
Here's a great article for learning Webpack step by step, starting from first principles: https://what-problem-does-it-solve.com/webpack/index.html
It also has a fantastic summary at the end describing what's wrong with Webpack and how to write better tools.
It also has a fantastic summary at the end describing what's wrong with Webpack and how to write better tools.
For those on .NET, we now have LibMan to save us.
https://blogs.msdn.microsoft.com/webdev/2018/04/17/library-m...
https://blogs.msdn.microsoft.com/webdev/2018/04/17/library-m...
ES6 modules will hopefully be great in a few years, but I just redid my own site https://mikemaccana.com (it's a nice, small project) to learn ES6 modules and some other new tech, and the lack of a repository even a hundredth the size of npm means you'll be spending a bunch of time downloading files, editing exports, and fixing dependencies between code. I'd be hesitant to use ES6 modules for a larger project as a result.
npm Inc recently joined TC39 so maybe that will change. Also if deno takes off, it's ES6 modules only.
npm Inc recently joined TC39 so maybe that will change. Also if deno takes off, it's ES6 modules only.
FYI, your site is kinda broken on my laptop (both Firefox and Chromium), I can only see part of the text at the bottom. You might want to tinker with that middle section with the slides.
Thanks for the heads up, I'll have a play. What's the vertical height of your display and zoom level?
(Firefox) 800px with system and browser bars, 900px in fullscreen, both missing text at 100% zoom level
Also, I noticed when the display area is resized, the slider resets (with animation) to the first slide, while the bottom text stays the same.
Also, I noticed when the display area is resized, the slider resets (with animation) to the first slide, while the bottom text stays the same.
Webpack4 got much slower with startup and recompilation of TS compared to 3.
ts-loader / fork-ts-checker-webpack-plugin maintainer here. I'm sorry to hear that's been your experience. It hasn't been my own; it could be worth you comparing your setup with one of the examples available. These are some good candidates:
https://github.com/TypeStrong/ts-loader/tree/master/examples...
https://github.com/TypeStrong/ts-loader/tree/master/examples...
https://github.com/TypeStrong/ts-loader/tree/master/examples... (written by Kenneth Chau of the Outlook.com team)
You may of course you may be using another typescript loader (there are several!). I thought it worth sharing in case you are using ts-loader and your config is catching you out.
Best of luck!
https://github.com/TypeStrong/ts-loader/tree/master/examples...
https://github.com/TypeStrong/ts-loader/tree/master/examples...
https://github.com/TypeStrong/ts-loader/tree/master/examples... (written by Kenneth Chau of the Outlook.com team)
You may of course you may be using another typescript loader (there are several!). I thought it worth sharing in case you are using ts-loader and your config is catching you out.
Best of luck!
As a ts-loader/fork-ts user thank you for all the work you do!.
Thanks a lot, I really appreciate your comment and will take a look. Keep up the great work!
Curious that wasn't my experience, it was about the same.
[deleted]
If you use Babel 7 alongside TS you can use the typescript preset to speed up builds a lot. The downside is that you don’t get typechecking on compilation.
Again, nodejs really pushes me away when each 'npm install' could install god knows how many modules/dependencies in that I have absolutely no idea or control, it just feels so bloated and unsafe sometimes.
because of that, plus now it is also used for frontend, it is no surprise the "packaging" tool becomes mandatory and complex.
so it's not really webpack's fault.
because of that, plus now it is also used for frontend, it is no surprise the "packaging" tool becomes mandatory and complex.
so it's not really webpack's fault.
A vanilla install of Phoenix with Brunch yields a node_modules with 388 packages. What are the odds of one of them becoming rogue due to a hack, and how would I know?
Add to this the overall (perhaps perceived) fragility of having to maintain a node project and fumbling with JavaScript. Node was a great new thing for server-side stuff, but whose idea was it to start using it for building every single command-line tool?