5 ms·

So what's the problem with a bundler/transpiler etc? You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abs

by quonn 3y ago

So what's the problem with a bundler/transpiler etc? You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abstraction basically never leaks. I never need to look at the transpiled files to find an error. Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.

jollyllama 3y ago
Once you're in the NPM ecosystem, there is a maintenance overhead. See: https://htmx.org/essays/no-build-step/ https://htmx.org/essays/no-build-step/ https://dubroy.com/blog/cold-blooded-software/ https://dubroy.com/blog/cold-blooded-software/
intrasight 3y ago
The problem is that it's no longer an "interpreted" language.
- quonn 3y ago
  How is that a problem?
  - intrasight 3y ago
    People like to interact with interpreted languages
    - quonn 3y ago
      But in the browser the browser interacts with it anyway. It‘s not like the app would run in a repl and now doesn‘t. There is no meaningful difference in this case, even less so if hot reloading is used.
danielvaughn 3y ago
I don't know how build systems work at lower levels, but things move so fast in the web development world that it renders your codebase inoperable if you don't maintain it. I've had a codebase that sat for as little as 6 months without me touching it. When I tried to run it again, I ran into so many compatibility issues that I had to tediously copy out all of my code into a new project and then fix the remaining issues with my code itself. Web dev build systems are dependencies on top of dependencies on top of dependencies, and they're all introducing breaking changes every other week it seems.
- quonn 3y ago
  That‘s why there is a lock file. The package manager and node version can likewise be locked.
  - ahmedfromtunis 3y ago
    Does the lock file render the need to update dependencies obsolete? Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble. Lock files are not a substitute for sane dependency management.
    - quonn 3y ago
      I responded to someone who claimed that it broke by itself after 6 months. Lock files prevent this.
    - satvikpendem 3y ago
      This is the same in any language then.
      - ahmedfromtunis 3y ago
        Some stacks are just more finicky than others: https://news.ycombinator.com/item?id=38959190 https://news.ycombinator.com/item?id=38959190
    - zdragnar 3y ago
      There's no reason that you absolutely have to update every dependency after 6 months. Not updating anything at all is perfectly fine. Nobody in their right mind thinks you can change major versions without some elbow grease in any other language.
      - ahmedfromtunis 3y ago
        > Nobody in their right mind thinks you can change major versions without some elbow grease in any other language. I have an old project that I didn't touch in more than 5 years. Last week, I decided to give it another spin, and booked the entire afternoon to deal with any issues that may arise from the update process. It went from Python 3.6 to 3.11, and from Django 2.2 to 4.2. Postgres jumped from 11 to 16! There were 10 other libraries (PIL, ...) that I had to update too. The only special procedure that I had to do was dumping data from the old database and restoring it from the new one, as recommended by PG when doing major-point updates. (And adding a single line to Django's `settings.py` for the new `CSRF_TRUSTED_ORIGINS`.) When I typed `docker compose up` on my terminal, the app just run smoothly without as single problem. I even had to check that I didn't invoke the old configuration by mistake. All in all, the process took me less than 15 minutes.
hellcow 3y ago
> You set it up once. It takes a few hours, maybe a day. Until you need to update a dependency on a large codebase, which takes weeks because dependency A doesn't work with dependency B version X, and updating dependency B means that it no longer works with dependency C version Y, and so on. And nobody uses dependency C anymore -- it's unmaintained, so you need to rewrite everything to use dependency D. Then you need to repeat this every few months because there's nonstop vulnerabilities flagged and APIs broken. Nah, I'm good.
- quonn 3y ago
  Dependency management is an unrelated issue and it exists for any platform. Unless you copy paste code or unless you just avoid dependencies. Which is easy to do in TypeScript as well. Nobody says you need to install hundreds of packages.
  - jacobyoder 3y ago
    > Nobody says you need to install hundreds of packages. If I need one, I have to get that package's dependencies. People don't choose to say "Damn, I'd really love to have 1800 dependencies!" But if you have 4-5, you automatically get dozens or hundreds out of your control. Yes, could you build everything yourself by hand? Sure. That's a hard sell to many depts/projects. "This will take 3 weeks to build" vs "This will take 4 minutes to npm install". That 4 minutes is introducing a lot of potential risk and headache and time later, but it's providing immediate relief. FWIW, "dependency management" is a problem in every platform, but I have nowhere near the same number of issues in the composer/php world (nor previously in the maven/java world) as I do in the npm/js world.
    - cryptonym 3y ago
      Publishing & importing 3rd party code is so easy with npm that everyone is blindly importing code that wouldn't pass their own peer reviews.
  - stiiv 3y ago
    Agreed! For this reason, we use very few third-party dependencies in our big TS monorepo. NPM is a jungle, and for an experienced team of TS developers, a new dependency just isn't worth the risk -- we'd rather just code things ourselves. But it is worth emphasizing that NPM really does stand out as a hazard compared to package repositories for other dev ecosystems. I believe that dangers are more common, and unpleasant outcomes can be more severe.
wmfiv 3y ago
One challenge a bundler and transpiler introduce is they enable an unconstrained set of solutions. If a particular application has 10 patterns that support all the applications UI interactions, then a simple, constrained solution like htmx that supports those 10 patterns is preferable (to me) than an unconstrained solution like Typescript + React where each developer will likely use their creativity and experience to design slightly or wildly bespoke solutions for each feature.
jabradoodle 3y ago
For one thing I may have very simple requirements that I don't want to buy into maybe a day long setup for, nor hand write js when html could support it.
mythz 3y ago
Reasons why I no longer prefer SPA's: - Build tools are complex - Large FX's have 100's of npm dependencies - Every SPA I've created has suffered from bitrot overtime, including: - Often breaking changes on upgrade, incompatibility between package versions - Dependencies/tools/fxs often abandoned, rewritten, replaced, etc - Constantly wasting time working around issues - Doesn't scale, the larger the App, the slower initial load and slower the FCP - Heavy client state and need to manage client routing I now prefer using #NoBuild [1] ESM builds of progressive JS FX's for adding behavior to static rendered content where each page only loads the JS it needs, which ends up being much simpler [2] and resolves these issues I used to have with SPAs. Blazor with static rendering and Enhanced Navigation is even nicer which gives SPA-like navigation responsiveness without SPA-like complexity [3]. [1] https://world.hey.com/dhh/you-can-t-get-faster-than-no-build-7a44131c https://world.hey.com/dhh/you-can-t-get-faster-than-no-build... [2] https://servicestack.net/posts/javascript https://servicestack.net/posts/javascript [3] https://servicestack.net/posts/net8-best-blazor https://servicestack.net/posts/net8-best-blazor
modmodmod 3y ago
best joke heard all day
gofreddygo 3y ago
> 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.
exabrial 3y ago
> This abstraction basically never leaks I actually did laugh out loud.
deliriumchn 3y ago
> It takes a few hours, maybe a day. Even then, most of the times it doesn't take even an hour because majority of people will grab default config or use something that allows no-config (parcel, vite, etc)... Some are fine with default CRA for a long time until they really need something custom, for example.

by quonn 3y ago

jollyllama 3y ago

Once you're in the NPM ecosystem, there is a maintenance overhead. See: https://htmx.org/essays/no-build-step/ https://htmx.org/essays/no-build-step/ https://dubroy.com/blog/cold-blooded-software/ https://dubroy.com/blog/cold-blooded-software/

intrasight 3y ago

The problem is that it's no longer an "interpreted" language.

quonn 3y ago
How is that a problem?
- intrasight 3y ago
  People like to interact with interpreted languages
  - quonn 3y ago
    But in the browser the browser interacts with it anyway. It‘s not like the app would run in a repl and now doesn‘t. There is no meaningful difference in this case, even less so if hot reloading is used.

danielvaughn 3y ago

I don't know how build systems work at lower levels, but things move so fast in the web development world that it renders your codebase inoperable if you don't maintain it. I've had a codebase that sat for as little as 6 months without me touching it. When I tried to run it again, I ran into so many compatibility issues that I had to tediously copy out all of my code into a new project and then fix the remaining issues with my code itself. Web dev build systems are dependencies on top of dependencies on top of dependencies, and they're all introducing breaking changes every other week it seems.

quonn 3y ago
That‘s why there is a lock file. The package manager and node version can likewise be locked.
- ahmedfromtunis 3y ago
  Does the lock file render the need to update dependencies obsolete? Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble. Lock files are not a substitute for sane dependency management.
  - quonn 3y ago
    I responded to someone who claimed that it broke by itself after 6 months. Lock files prevent this.
  - satvikpendem 3y ago
    This is the same in any language then.
    - ahmedfromtunis 3y ago
      Some stacks are just more finicky than others: https://news.ycombinator.com/item?id=38959190 https://news.ycombinator.com/item?id=38959190
  - zdragnar 3y ago
    There's no reason that you absolutely have to update every dependency after 6 months. Not updating anything at all is perfectly fine. Nobody in their right mind thinks you can change major versions without some elbow grease in any other language.
    - ahmedfromtunis 3y ago
      > Nobody in their right mind thinks you can change major versions without some elbow grease in any other language. I have an old project that I didn't touch in more than 5 years. Last week, I decided to give it another spin, and booked the entire afternoon to deal with any issues that may arise from the update process. It went from Python 3.6 to 3.11, and from Django 2.2 to 4.2. Postgres jumped from 11 to 16! There were 10 other libraries (PIL, ...) that I had to update too. The only special procedure that I had to do was dumping data from the old database and restoring it from the new one, as recommended by PG when doing major-point updates. (And adding a single line to Django's `settings.py` for the new `CSRF_TRUSTED_ORIGINS`.) When I typed `docker compose up` on my terminal, the app just run smoothly without as single problem. I even had to check that I didn't invoke the old configuration by mistake. All in all, the process took me less than 15 minutes.

hellcow 3y ago

> You set it up once. It takes a few hours, maybe a day. Until you need to update a dependency on a large codebase, which takes weeks because dependency A doesn't work with dependency B version X, and updating dependency B means that it no longer works with dependency C version Y, and so on. And nobody uses dependency C anymore -- it's unmaintained, so you need to rewrite everything to use dependency D. Then you need to repeat this every few months because there's nonstop vulnerabilities flagged and APIs broken. Nah, I'm good.

quonn 3y ago
Dependency management is an unrelated issue and it exists for any platform. Unless you copy paste code or unless you just avoid dependencies. Which is easy to do in TypeScript as well. Nobody says you need to install hundreds of packages.
- jacobyoder 3y ago
  > Nobody says you need to install hundreds of packages. If I need one, I have to get that package's dependencies. People don't choose to say "Damn, I'd really love to have 1800 dependencies!" But if you have 4-5, you automatically get dozens or hundreds out of your control. Yes, could you build everything yourself by hand? Sure. That's a hard sell to many depts/projects. "This will take 3 weeks to build" vs "This will take 4 minutes to npm install". That 4 minutes is introducing a lot of potential risk and headache and time later, but it's providing immediate relief. FWIW, "dependency management" is a problem in every platform, but I have nowhere near the same number of issues in the composer/php world (nor previously in the maven/java world) as I do in the npm/js world.
  - cryptonym 3y ago
    Publishing & importing 3rd party code is so easy with npm that everyone is blindly importing code that wouldn't pass their own peer reviews.
- stiiv 3y ago
  Agreed! For this reason, we use very few third-party dependencies in our big TS monorepo. NPM is a jungle, and for an experienced team of TS developers, a new dependency just isn't worth the risk -- we'd rather just code things ourselves. But it is worth emphasizing that NPM really does stand out as a hazard compared to package repositories for other dev ecosystems. I believe that dangers are more common, and unpleasant outcomes can be more severe.

wmfiv 3y ago

One challenge a bundler and transpiler introduce is they enable an unconstrained set of solutions. If a particular application has 10 patterns that support all the applications UI interactions, then a simple, constrained solution like htmx that supports those 10 patterns is preferable (to me) than an unconstrained solution like Typescript + React where each developer will likely use their creativity and experience to design slightly or wildly bespoke solutions for each feature.

jabradoodle 3y ago

For one thing I may have very simple requirements that I don't want to buy into maybe a day long setup for, nor hand write js when html could support it.

mythz 3y ago

Reasons why I no longer prefer SPA's: - Build tools are complex - Large FX's have 100's of npm dependencies - Every SPA I've created has suffered from bitrot overtime, including: - Often breaking changes on upgrade, incompatibility between package versions - Dependencies/tools/fxs often abandoned, rewritten, replaced, etc - Constantly wasting time working around issues - Doesn't scale, the larger the App, the slower initial load and slower the FCP - Heavy client state and need to manage client routing I now prefer using #NoBuild [1] ESM builds of progressive JS FX's for adding behavior to static rendered content where each page only loads the JS it needs, which ends up being much simpler [2] and resolves these issues I used to have with SPAs. Blazor with static rendering and Enhanced Navigation is even nicer which gives SPA-like navigation responsiveness without SPA-like complexity [3]. [1] https://world.hey.com/dhh/you-can-t-get-faster-than-no-build-7a44131c https://world.hey.com/dhh/you-can-t-get-faster-than-no-build... [2] https://servicestack.net/posts/javascript https://servicestack.net/posts/javascript [3] https://servicestack.net/posts/net8-best-blazor https://servicestack.net/posts/net8-best-blazor

modmodmod 3y ago

best joke heard all day

gofreddygo 3y ago

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

exabrial 3y ago

> This abstraction basically never leaks I actually did laugh out loud.

deliriumchn 3y ago

> It takes a few hours, maybe a day. Even then, most of the times it doesn't take even an hour because majority of people will grab default config or use something that allows no-config (parcel, vite, etc)... Some are fine with default CRA for a long time until they really need something custom, for example.