5 ms·

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 lay

by divan 8y ago

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."

danielbarla 8y ago
> 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?
- divan 8y ago
  > 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.
tonetheman 8y ago
> 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.
- Wintamute 8y ago
  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.
  - duhi88 8y ago
    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.
  - sametmax 8y ago
    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.
    - pluma 8y ago
      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.
duhi88 8y ago
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.
- arkh 8y ago
  Shouldn't an IDE be able to do most of this?
- divan 8y ago
  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.

by divan 8y ago

danielbarla 8y ago

> 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?

divan 8y ago
> 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.

tonetheman 8y ago

> 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.

Wintamute 8y ago
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.
- duhi88 8y ago
  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.
- sametmax 8y ago
  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.
  - pluma 8y ago
    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.

duhi88 8y ago

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.

arkh 8y ago
Shouldn't an IDE be able to do most of this?
divan 8y ago
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.