7 ms·

Maybe you do but I don't. I spent a week learning Webpack four years ago and it's been paying dividends ever since. 99% of my job is building features, <1% is f

by ng12 7y ago

Maybe you do but I don't. I spent a week learning Webpack four years ago and it's been paying dividends ever since. 99% of my job is building features, <1% is fuddling with tooling and configuration. 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.

microcolonel 7y ago
Of all the bundlers and build systems, Webpack has been the most productive for me by far. We had a heck of a time with a couple of bundlers we were trying out a few months ago, and when we switched to Webpack, all of the things we struggled with on the previous bundlers came together seamlessly in less than half an hour.
pdimitar 7y ago
> 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.
- ng12 7y ago
  Your choice is to not build an SPA. There's nothing wrong with HTML, jQuery, and Bootstrap. I'm fairly convinced most JavaScript fatigue is the result of trying to build very simple web pages with tools designed for 10k+ LoC SPAs.
  - pdimitar 7y ago
    Part of the time you're right. But I do like to dabble with JS again -- after being backender only for years -- and I want to future-proof my work (if at all possible in the JS land). And I throw my hands in the air every time. Stuff like React or Vue generators seem to work fine but then I am left confused what do all the files do and why don't I have a stricter control over what gets pulled inside the project.
    - naniwaduni 7y ago
      > and I want to future-proof my work (if at all possible in the JS land). how often has this panned out for you?
      - pdimitar 7y ago
        Never. Still looking for ways. JS ecosystem is immature.
    - root_axis 7y ago
      Use the tools you understand to solve the problems at hand. The ecosystem wasn't built to optimize convenience for hobbyists, these tools have evolved over time to address specific needs, if you can't articulate the specific needs being addressed by every component in your asset pipeline, you shouldn't be using them.
      - pdimitar 7y ago
        Fair to a degree, I guess. Still, in the years during which I didn't work with JS, I picked like 5 other languages and even though they weren't exactly beginner-friendly I still managed rather quickly. JS though, always has been the exception. I understand what transpiling and bundling and minifying etc. are. But the tooling is somehow... don't know, hard to work with. And sometimes you get errors even in newly generated projects. It's indeed hard to articulate the problems but that’s because I've only done isolated toe-dipping for a while now, not because I don’t understand something. JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem.
        root_axis 7y ago
        > It's indeed hard to articulate the problems but that’s because I've only done isolated toe-dipping for a while now, not because I don’t understand something Exactly. I don't think your proficiency as a developer is in question, the issue is that your approach is backwards. You're searching for a reason to justify why you should use these tools, rather than trying to build a piece of software with specific requirements and then determining which tools facilitate that goal. > JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem The ecosystem already represents millions of developer hours distilled into "shortcuts" that allow developers to achieve capabilities that are very impractical without those tools. The idea of a "universal approach" in open-source makes no sense, people use the tools that best solve the problems they encounter, there will never be a one-size fits all solution, you have to understand the problem you're facing in order to pick the correct tool for the job.
hqjs 7y ago
Try https://hqjs.org/ https://hqjs.org/ it can do much more with much less effort. It supports all popular frameworks out of the box plus metalanguages like typescript and scss, and it takes care of polyfills

by ng12 7y ago

microcolonel 7y ago

Of all the bundlers and build systems, Webpack has been the most productive for me by far. We had a heck of a time with a couple of bundlers we were trying out a few months ago, and when we switched to Webpack, all of the things we struggled with on the previous bundlers came together seamlessly in less than half an hour.

pdimitar 7y ago

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

ng12 7y ago
Your choice is to not build an SPA. There's nothing wrong with HTML, jQuery, and Bootstrap. I'm fairly convinced most JavaScript fatigue is the result of trying to build very simple web pages with tools designed for 10k+ LoC SPAs.
- pdimitar 7y ago
  Part of the time you're right. But I do like to dabble with JS again -- after being backender only for years -- and I want to future-proof my work (if at all possible in the JS land). And I throw my hands in the air every time. Stuff like React or Vue generators seem to work fine but then I am left confused what do all the files do and why don't I have a stricter control over what gets pulled inside the project.
  - naniwaduni 7y ago
    > and I want to future-proof my work (if at all possible in the JS land). how often has this panned out for you?
    - pdimitar 7y ago
      Never. Still looking for ways. JS ecosystem is immature.
  - root_axis 7y ago
    Use the tools you understand to solve the problems at hand. The ecosystem wasn't built to optimize convenience for hobbyists, these tools have evolved over time to address specific needs, if you can't articulate the specific needs being addressed by every component in your asset pipeline, you shouldn't be using them.
    - pdimitar 7y ago
      Fair to a degree, I guess. Still, in the years during which I didn't work with JS, I picked like 5 other languages and even though they weren't exactly beginner-friendly I still managed rather quickly. JS though, always has been the exception. I understand what transpiling and bundling and minifying etc. are. But the tooling is somehow... don't know, hard to work with. And sometimes you get errors even in newly generated projects. It's indeed hard to articulate the problems but that’s because I've only done isolated toe-dipping for a while now, not because I don’t understand something. JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem.
      - root_axis 7y ago
        > It's indeed hard to articulate the problems but that’s because I've only done isolated toe-dipping for a while now, not because I don’t understand something Exactly. I don't think your proficiency as a developer is in question, the issue is that your approach is backwards. You're searching for a reason to justify why you should use these tools, rather than trying to build a piece of software with specific requirements and then determining which tools facilitate that goal. > JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem The ecosystem already represents millions of developer hours distilled into "shortcuts" that allow developers to achieve capabilities that are very impractical without those tools. The idea of a "universal approach" in open-source makes no sense, people use the tools that best solve the problems they encounter, there will never be a one-size fits all solution, you have to understand the problem you're facing in order to pick the correct tool for the job.

hqjs 7y ago

Try https://hqjs.org/ https://hqjs.org/ it can do much more with much less effort. It supports all popular frameworks out of the box plus metalanguages like typescript and scss, and it takes care of polyfills