3 ms·

Of course it is. So is JavaScript. I've done stuff in C, C++, Haskell, python and am now writing primarily in js. Nothing weird there. I fight more with librari

Of course it is. So is JavaScript. I've done stuff in C, C++, Haskell, python and am now writing primarily in js. Nothing weird there. I fight more with libraries than with the language.

weberc2 7y ago
The bit I fight with the most is how to package it all up for distribution. I'm not a frontend dev, and I vaguely understand that the answer is "webpack" but it's not clear to me what the happy path is for configuring this for distribution. It's also not clear to me whether these $LANG->WASM toolkits will solve this problem or whether they'll also need something like webpack.
- marcus_holmes 7y ago
  Webpack gives me the screaming heeby-jeebies. Last time I looked, there were minimisation plugins for Gulp/Grunt, etc that would package JS up.
  - maemilius 7y ago
    Why? Webpack has gotten significantly easier to get up and running with since Webpack 4 (iirc). Sure, it starts getting complicated if you want to add language features that haven't made it into browsers yet (i.e. Babel) or use something that transpiles to JavaScript (e.g. TypeScript), but the really popular ones have plenty of good documentation on how to set them up and what each piece is doing. I've only had to set up Webpack a couple times and I've already internalized most of the important stuff. Source Maps are still black magic to me though...
    - weberc2 7y ago
      Our webpack builds are really slow and we can’t seem to figure out how to profile it.
    - marcus_holmes 7y ago
      It's taken me 8 days to answer, because I've rewritten this a few times. I may write this up as a blog post. OK, so... 1. It doesn't do one job and do it well. It tries to do it all. 2. It has magic. Why does this setting do this? Don't know, just do it. 3. It's vastly overcomplicated (related to 1, and produces 2) 4. It's a black box. It's not at all transparent about how it does what it does, and the output it produces seems to be arbitrary. I mean, you could probably work back from the minimised mess that you get to relate it to the source, probably. But it's not at all clear why tweaking this declaration makes that function move to that module. 5. It's not instrumented, or predictable. Changing a declaration can make it double its processing time, and there's no way of knowing which of the 5 changes you just made caused that. And finally... It's a solution to a problem that only exists because of the dependency culture in the JS community. Because each dependency contains a lot more code than is needed to solve the one problem it was imported to solve, web apps tend to bloat. So we need to break them into modules and only import the modules we need. So we need a tool to do that and package the modules up. So we get Webpack. Instead, why don't we just import less code in the first place? We really (and I mean really) don't need 500Kb of javascript to create a basic web app. If we could cut that down to 100Kb then we could just minimise it and we wouldn't need webpack at all (maybe Gulp to run Babel for those oh-so-necessary new cool JS features).
- freddex 7y ago
  I switched from Webpack to Parcel (https://parceljs.org/ https://parceljs.org/), it requires far less configuration (only command line parameters for me) and runs faster. It's "batteries included", and I find it's enough for most of my applications.
- Roboprog 7y ago
  I’m a somewhat (?) unusual situation where we are a Java shop in which I persuaded the group a few years ago to move to an SPA on top of web services (REST, JSON) architecture... That said, I’m using the Maven plugin which runs the Google Closure compiler to bundle my js files (and strip white space, but not name-mangling). Seems to get the job done. Note: most of the files are just a few large “IIFE”s to be concatenated together, rather than “modules” or such, as we had a requirement to support IE11, and were initially sticking with ES5 style.

Of course it is. So is JavaScript. I've done stuff in C, C++, Haskell, python and am now writing primarily in js. Nothing weird there. I fight more with libraries than with the language.

weberc2 7y ago

The bit I fight with the most is how to package it all up for distribution. I'm not a frontend dev, and I vaguely understand that the answer is "webpack" but it's not clear to me what the happy path is for configuring this for distribution. It's also not clear to me whether these $LANG->WASM toolkits will solve this problem or whether they'll also need something like webpack.

marcus_holmes 7y ago
Webpack gives me the screaming heeby-jeebies. Last time I looked, there were minimisation plugins for Gulp/Grunt, etc that would package JS up.
- maemilius 7y ago
  Why? Webpack has gotten significantly easier to get up and running with since Webpack 4 (iirc). Sure, it starts getting complicated if you want to add language features that haven't made it into browsers yet (i.e. Babel) or use something that transpiles to JavaScript (e.g. TypeScript), but the really popular ones have plenty of good documentation on how to set them up and what each piece is doing. I've only had to set up Webpack a couple times and I've already internalized most of the important stuff. Source Maps are still black magic to me though...
  - weberc2 7y ago
    Our webpack builds are really slow and we can’t seem to figure out how to profile it.
  - marcus_holmes 7y ago
    It's taken me 8 days to answer, because I've rewritten this a few times. I may write this up as a blog post. OK, so... 1. It doesn't do one job and do it well. It tries to do it all. 2. It has magic. Why does this setting do this? Don't know, just do it. 3. It's vastly overcomplicated (related to 1, and produces 2) 4. It's a black box. It's not at all transparent about how it does what it does, and the output it produces seems to be arbitrary. I mean, you could probably work back from the minimised mess that you get to relate it to the source, probably. But it's not at all clear why tweaking this declaration makes that function move to that module. 5. It's not instrumented, or predictable. Changing a declaration can make it double its processing time, and there's no way of knowing which of the 5 changes you just made caused that. And finally... It's a solution to a problem that only exists because of the dependency culture in the JS community. Because each dependency contains a lot more code than is needed to solve the one problem it was imported to solve, web apps tend to bloat. So we need to break them into modules and only import the modules we need. So we need a tool to do that and package the modules up. So we get Webpack. Instead, why don't we just import less code in the first place? We really (and I mean really) don't need 500Kb of javascript to create a basic web app. If we could cut that down to 100Kb then we could just minimise it and we wouldn't need webpack at all (maybe Gulp to run Babel for those oh-so-necessary new cool JS features).
freddex 7y ago
I switched from Webpack to Parcel (https://parceljs.org/ https://parceljs.org/), it requires far less configuration (only command line parameters for me) and runs faster. It's "batteries included", and I find it's enough for most of my applications.
Roboprog 7y ago
I’m a somewhat (?) unusual situation where we are a Java shop in which I persuaded the group a few years ago to move to an SPA on top of web services (REST, JSON) architecture... That said, I’m using the Maven plugin which runs the Google Closure compiler to bundle my js files (and strip white space, but not name-mangling). Seems to get the job done. Note: most of the files are just a few large “IIFE”s to be concatenated together, rather than “modules” or such, as we had a requirement to support IE11, and were initially sticking with ES5 style.