Hacker News Reader

> What I found was that the biggest barrier to entry was configuring webpack to be "just right".

As someone who has just spent a whole week trying to plumb Vite + Rollup into an ASP.NET web application, I can relate to this on many levels.

I can produce 90% of our functionality with vanilla javascript + a sprinkling of JQuery, but to get something 'modern' in Vue.JS fitting into the application comfortably is a bloody chore. Sparing the gory details, it feels like orchestrating a thousand moving parts while being blind with a gun named 'ship or die' held to your back.

For comparison, the EF core at least gives me logs. C# is a delight to debug. Print statements can tell me what I need. These parts feel wholistic.

Yet the web stuff is just so scattered, so much to configure, so many options where if you want to do something even slightly non-standard you are in the dark, mashing the conf files until it works and you aren't even sure why but you have to move on.

This feels different from mastering one language, even though it has a steep learning curve. I hit roadblocks in perl but they weren't as frustrating and it felt like everything was feeding back to a cohesive whole. With webdev, it doesn't feel like that at all. I don't know why, I wish it wasn't so.

Yep, you're walking in one of the voids that is largely ignored by modern front end web dev. Frameworks like React and Vue advertise that your can easily add them to any page and that's technically true... but when you have a real world app built with a backend framework and you want to integrate it with React/Vue in a sane way... good luck to you!

All the pieces exist to make it work, but you won't find much documentation to help you. You'll have to rely finding blog posts, but of course if the post is more than a year old most of the libs or tools they're talking about will have totally changed. Once you do get everything up and running you'll often find that the dev experience is less than great.

That is really unfortunate. Webpack is a nightmare and outdated. I wonder how you came to use it? Node has a nice intro: https://nodejs.org/en/learn/getting-started/nodejs-with-type... (skip ts-node and go directly to tsx). Or Deno or Bun run your TS code directly. Modern frontend frameworks like Vue or Svelte have their own tooling, mostly based on Vite and Esbuild. I think it was just bad luck that you came across Webpack ...

I know you're trying to help, but this further highlights the problem with frontend dev.

It’s like Gradle vs Maven for the Java ecosystem.

They do fundamentally the same things but with very different approaches and tradeoffs.

Webpack and Vite are very different approaches to the same problem with different tradeoffs[0][1]

[0]: namely, webpack and its inevitable successor rspack, are way more flexible and arguably powerful but at the cost of higher complexity and more proprietary features like the webpack/rspack specific runtime. Superior in asset handling though, in many respects, and the high level of optimizations you make once you hit a certain complexity threshold is greater than what Vite/Rolluo has currently without extensive custom plugins

[1]: Vite or Rollup is most likely what most projects need. I’d recommend always starting there, as most of the advanced and flexible features of webpack/rspack are very much not what most need

Yes, so on the only sizeable TS project I did (which was a library, to be used by other teams) I bypassed webpack entirely and went for a mixture of tsc and esbuild. But knowing to steer clear of webpack (or even - that you can!) is a barrier.

Yep. Webpack is absolutely terrible but still unfortunately seems to have a lot of mindshare.

I use TypeScript and esbuild for all my stuff. Even then, I often spend a crazy amount of time getting modules working.

Between the various TypeScript module options and various package.json module options (and various code patterns used), modules make JavaScript way more painful than it should be.

I think most of the JS language standards work the past 10 years has been awesome, but modules was definitely rushed and poorly thought though, causing years of frustration.

I agree that config and tooling are the hardest part of getting Typescript working. Everybody is saying use a framework, but if your use case deviates from the frameworks it can get pretty difficult. My use case that was very tricky to config was.

- SSR rendering of react in an express app (both typescript).

-Trying to get VSCode visual debugger to work for both the client and server code paths.

- Getting the various test libraries to work correctly (I still can’t get the NYC code coverage library to work).

- Mix of ESM, CommonJS, misconfigured npm packages that don’t expose their types correctly.

I ultimately used Vite, and got things working 90% the way I wanted and called it good enough.

If you’re using vite you should use Vitest with code coverage. NYC is redundant at that point

Never start with Webpack. Use Vite with a template and go from there.

Or just go straight to esbuild. I've found vite just makes things more complicated and slower. Particularly, the "smart reloading" breaks in subtle ways and turning every source file into a request doesn't scale well. This can probably be configured away somehow, but again, that just makes things more complicated.

Remix. Vite done right, mostly pre-configured out of the box.

If you want to spend a minute or two waiting before your server is back up after making any kind of change, Remix sounds about right.

My project is relatively tiny too. I’ve never regretted a choice more than Remix.

My projects reload instantly in WSL, what environment are you using?

A minute or two? A sizeable Rails web app I am working on takes maybe 5 seconds to start...

> Remix. Vite done right…

Remix is moving to Vite as its default compiler. https://remix.run/docs/en/main/guides/vite

I'm aware, I've been on the experimental vite branch for a while. It is literally "vite, done right"

Vue, Nuxt or Svelte are even better. No need to waste time and energy with React and it's peculiarities. However, if you want or must React, then Remix, hands down.

While I very much like svelte, it's not fully mature yet and it doesn't have a very deep ecosystem, plus the additional hiring time/cost basically means building anything other than a small scale solo project with it is going to end you up in the red.

On the Vue vs React debate, honestly it comes down to preferring templates vs components. Vue is simpler but there are good reasons for a lot of the React complexity, and React still has a stronger ecosystem and more developers.

But then you have to waste time with vue/sveltes particularities ;). It's just a matter of what you're used to imo

The request-per-module thing only happens with the Vite dev server: production builds are bundled with rollup similar to webpack.

I'd make the exact opposite suggestion: Always use WebPack. There will be a package in the future that has a particular WebPack configuration to make; and you don't want to figure out how to do that in another bundler.

No thanks. Avoiding those hypothetical future packages is a better tradeoff.

I’m always amazed to see the number of SaaS companies based over here in the more privacy focused, non-Microsoft open source EU centric spaces, that use PHP but without a care in the world for strict typing.

It leads to scenarios where I receive OpenApi specs that loom like this:

   type:
     - string/integer

They just don’t give a shit because this kind of crap works in PHP.

They could use:

   oneOf:
     - type: string
     - type: integer

Which is nastier to deal with a typed language client, but at least it conforms to the spec.

So thank you for actually caring about types in PHP.

And even after all the work configuring webpack, did you have readable stacktraces when an error happens?

Thank you. The replies to your post all seem variants of “you should’ve used X instead of Y”, but when you’re transpiling, you’re inviting a world of subtle bugs and edge cases. The added value, if it at all exists, is almost never worth the trouble, IMO.

tsx, esbuild, Bun, Deno, etc...all things that don't require you to use Webpack and just write/run TS...

it's worth pointing out Evan (co-founder of Figma) also created esbuild.

Aren’t there enough frameworks available to avoid Webpack? Seems pretty low level for app developers these days.

I’ve done Webpack configurations and Browserify before that. I’ll be glad if I never go there again.

As a solo dev with a successful electron app I can say that the 5+ year journey from babel+flow+webpack to typescript+webpack, between two targets (main node and renderer chromium) not to mention native modules, node ABI, dual package jsons, electron itself as a giant shifting foundation… has been one of the most intimidating challenges in my dev career and I’m coming out the other side much stronger and confident. Props to everyone involved.

This is the reason that JS frameworks are a thing. Next is buggy and overbuilt, but Remix is pretty much plug and play, I strongly recommend checking it out.

Im surprised that Remix doesn’t get much love in the community. Or is it because Vercel and their influencer team is yelling so loud about Next that we can’t hear the Remix people?

I feel like Remix is rising pretty fast. The death of create-react-app has pushed people to frameworks and Next (while loudly marketed by Vercel) feels overweight and underpolished for people who just want something that focuses on the most common use cases with minimal setup / fiddling where remix shines.

It’s going to take some time but it’s going to take over.

Next really fucked up with the app router, and people are realizing everything is just a trap to get more customers on vercel.

+1

I’ve been using remix for the last 6 months and I’m super happy with it.

You want to do a lot but you don't want to pay for it. There is a shit ton of complexity on the web and the current frameworks (ie: NextJS/React/TypeScript) try to hide/manage this complexity but this only goes so far.

As soon as you hit an edge outside of their matrix of management you open the dark Pandora box of front-end development.

You don't have to transpile anything, you can just put your TS types in JavaScript comments. Or am I missing something?

Do you get any editor support when going this route?

Yes, vscodium just works.

You can, but it's ugly and time-consuming. And makes it harder to parse what's actually a comment.

Webpack is legacy.