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