Hacker News Reader

Comment by julik | Hacker News Reader

It is actually a fairly indicative story. At the start there is a brilliant individual (Evan) who sets up an entire toolchain + core of the product. They then move on (or get pushed out, or get bored), and with the team (and the product) now being much bigger, things get replatformed to a more familiar, widely used stack. The success of these steps heavily depends on how robust the eng culture is at the organisation. I suspect (no evidence though!) that Evan and other founders have set up an excellent eng culture at Figma and even if they make a mistake at some point, there is sufficient resilience in place to correct. All power to them!

View on HN

It's ironic. For the past 5 years I've been writing type strict PHP. People love to shit on PHP yet I found that when I started using strict types my code quality improved, amount of lines needed to produce a result decreased, and necessary unit tests to produce the same result also decreased.

Then a few months ago I decided to write a TS project from scratch. For the record I have 18 years of JavaScript experience. What I found was that the biggest barrier to entry was configuring webpack to be "just right". Other devs on my team with similar level of experience would have their eyes glaze over when webpack came up and get annoyed. For good reason. It took me several days to get it to work right. The fact that the tsconfig has 20 options that can effect the transpiler and not have good docs is a problem. The fact that there needs to be two tsconfigs in a react native project that compiles down to web as a secondary build target is another problem. The fact that you need a very experienced dev to spend days configuring webpack is another problem. Finding information about the right configuration is like the blind leading the blind. Most search results on the topic are riddled with half truths and non sense. Many devs rely on a preexisting webpack config and if they do anything to mess it up they are many times completely unable to fix it.

Typescript is fine. I guess. The code produced is nicer. But having to rely on webpack is an issue.

I actually like TS but I wish I didn't need to transpile anything or have to bang my head against a webpack config for days. It's by far the biggest barrier to entry because while you're banging your head against it you're not writing code. And for none technical stake holders when you have nothing visual to show at stand ups that can create friction and make the engineers seem like they aren't doing anything.

So far at multiple companies I've had to configure webpack for extremely complex JavaScript based single page apps which took me literally months of messing around with it until it worked just right. And until it does work "just right" the non technical folks think you're wasting time.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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

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

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.

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.

Webpack is legacy.

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.

I remember when I first read this blog post, https://www.figma.com/blog/how-we-built-the-figma-plugin-sys.... Besides now feeling a bit old realizing this was 5 years ago, I remember thinking what an amazing engineering culture they must have at Figma (besides having a bunch of brilliant people). I mean, they talked about essentially trying out a tech path for a month and then deciding that path was a dead end - I find this so rare in startups where there is a lot of pressure to continually demonstrate "progress".

As a corollary, though, I think those kinds of cultures are only possible if your team is composed of primarily brilliant people, because these brilliant people can move faster than most competitors even if they do wander down an unproductive path for a while, and there is total trust that the folks on your team are capable and self-motivated.

Reply on news.ycombinator.com