3 ms·

> what's the problem with a bundler/transpiler Problem is why do we even need one? All I'm trying to do is for my client code to update a part of the page and

> what's the problem with a bundler/transpiler Problem is why do we even need one? All I'm trying to do is for my client code to update a part of the page and not the entire page. Why do I need to even introduce concepts of bundling and transpiling for this pig-headed simple task ? Further, react has a steep learning curve that a backend person need not be subjected to. And it evolves, so that search-copy-paste phase just never ends. And then dependencies update. Another comment here details why that is a nightmare. If you want to feel the pain, search for any react project from 2 years ago on github or even some showhn projects here. Literally none of them even start ! So you see htmx does address a group just like react does. Its a tool and it's great at what it does.

quonn 3y ago
TypeScript is simply a much more robust type-safe language and the compiler abstracts away subtle differences between browsers. Likewise React abstracts away subtle differences between browsers. And most applications are far more complex than just needing to update a small part of the page.
quonn 3y ago
They don‘t start if they use complex frameworks, many dependencies, don‘t use lock files, don‘t lock their package manager and don‘t lock nodeJS and don‘t use Docker. If they use plain TypeScript and plain React, have a lock file, lock their package manager version and lock their nodeJS version and optionally ship a sane Docker setup they will certainly run. It is true that it would be nice to have a single tool that combines a bundler, typescript, linter, prettier, package manager and runtime and have it all configured with reasonable defaults from a single file and not 5 configs. And people have tried this lately, with approaches like deno and bun. But it‘s difficult to get these adopted. Still, it would be better for someone to take all these tools and freeze them in place or even fork them and then freeze them with only bug fixes coming, rather than throwing out 10 years of progress and going back to something that just doesn‘t work.
- gofreddygo 3y ago
  Lockfiles aren't a magic bullet. They point to an a specific old version of all internal dependencies. That still requires the maintainer of each of my dependencies to have published a patch to an OLD version when vulns show up. And the alternative of typscript + react + nodejs + npm + docker for a damn web based UI is just terrible ! Sorry, no bueno. I don't want to be at the mercy of all the maintainers of my dependencies. So clearly, I need to cut down on my dependencies. htmx is a great middle ground. Clearly, you can now at least see the appeal of htmx + a backend service for a robust though not fully optimized web based app. And I can't see the JS ecosystem's last 10 years as outright "progress", but rather a series of experiments, that work for some and don't for others.
  - quonn 3y ago
    Many of these libraries cannot have meaningful vulnerabilities. What‘s a possible vulnerability in lodash that can be exploited without already being able to inject code? Furthermore, any vulnerability in a dependency could also exist in code written by myself or a team member. And then never get fixed or even found.

quonn 3y ago

TypeScript is simply a much more robust type-safe language and the compiler abstracts away subtle differences between browsers. Likewise React abstracts away subtle differences between browsers. And most applications are far more complex than just needing to update a small part of the page.

quonn 3y ago

They don‘t start if they use complex frameworks, many dependencies, don‘t use lock files, don‘t lock their package manager and don‘t lock nodeJS and don‘t use Docker. If they use plain TypeScript and plain React, have a lock file, lock their package manager version and lock their nodeJS version and optionally ship a sane Docker setup they will certainly run. It is true that it would be nice to have a single tool that combines a bundler, typescript, linter, prettier, package manager and runtime and have it all configured with reasonable defaults from a single file and not 5 configs. And people have tried this lately, with approaches like deno and bun. But it‘s difficult to get these adopted. Still, it would be better for someone to take all these tools and freeze them in place or even fork them and then freeze them with only bug fixes coming, rather than throwing out 10 years of progress and going back to something that just doesn‘t work.

gofreddygo 3y ago
Lockfiles aren't a magic bullet. They point to an a specific old version of all internal dependencies. That still requires the maintainer of each of my dependencies to have published a patch to an OLD version when vulns show up. And the alternative of typscript + react + nodejs + npm + docker for a damn web based UI is just terrible ! Sorry, no bueno. I don't want to be at the mercy of all the maintainers of my dependencies. So clearly, I need to cut down on my dependencies. htmx is a great middle ground. Clearly, you can now at least see the appeal of htmx + a backend service for a robust though not fully optimized web based app. And I can't see the JS ecosystem's last 10 years as outright "progress", but rather a series of experiments, that work for some and don't for others.
- quonn 3y ago
  Many of these libraries cannot have meaningful vulnerabilities. What‘s a possible vulnerability in lodash that can be exploited without already being able to inject code? Furthermore, any vulnerability in a dependency could also exist in code written by myself or a team member. And then never get fixed or even found.