I don’t understand why the screenshot of the view on the right could not be created with htmx (or any UI framework/library).
Why Gumroad Didn't Choose Htmx
31–40 of 216 posts
Re: Why Gumroad Didn't Choose Htmx
#32> AI and Tooling Support: It’s worth noting that AI tools are intimately familiar with Next.js and not so much with htmx This is stated as a very matter-of-fact downside, but this is a pretty crazy portent for the future of dev tools / libraries / frameworks / languages. Predictions: - LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools - LLMs will encourage usage of open-source to…
I had written a comment addressing this as well but you beat me to it. In a way it is similar to the effect StackOverflow had on popular libraries, but amplified. Even without StackOverflow, a library can do well if it has good documentation. I'm not sure if the same holds true with LLMs.
Re: Why Gumroad Didn't Choose Htmx
#33> AI and Tooling Support: It’s worth noting that AI tools are intimately familiar with Next.js and not so much with htmx This is stated as a very matter-of-fact downside, but this is a pretty crazy portent for the future of dev tools / libraries / frameworks / languages. Predictions: - LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools - LLMs will encourage usage of open-source to…
My prediction is that it'll be like this for a while, but as soon as tooling becomes better and the context of current APIs + local files gets better taken into consideration, this "advantage" will disappear.
Re: Why Gumroad Didn't Choose Htmx
#34My comment from the other thread: The CEO of gumroad mentioned on twitter that he had tried out htmx for a project but decided to go with NextJS instead. I asked him if he was willing to write up his experience and he graciously agreed to do so. I have been looking for a thoughtful negative experience with htmx to host on the htmx website and I am very thankful he was willing to put in the work to produce one.
> other thread
Re: Why Gumroad Didn't Choose Htmx
#35> AI and Tooling Support: It’s worth noting that AI tools are intimately familiar with Next.js and not so much with htmx This is stated as a very matter-of-fact downside, but this is a pretty crazy portent for the future of dev tools / libraries / frameworks / languages. Predictions: - LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools - LLMs will encourage usage of open-source to…
This will not be true for future frameworks, though it is likely true for current ones.
Future frameworks will be designed for AI and enablement. There will be a reversal in convention-over-configuration. Explicit referencing and configuration allow models to make fewer assumptions with less training.
All current models are trained on good and bad examples of existing frameworks. This is why asking an LLM to “code like John Carmack” produces better code.. Future frameworks can quickly build out example documentation and provide it within the framework for AI tools to reference directly.
Re: Why Gumroad Didn't Choose Htmx
#36> I thought htmx could be a good solution to keep our front-end super light.
It seems htmx stopped working as soon as you gave up on the super light frontend part :)
You started using third party libraries to render complex UI/UX and state management.
Also, I’d like to point out that saying “it was easier to do X in React” is not really fair if you did that using third-party libraries. It’s just that somebody did it for you so that you didn’t have to.
I sympathise a lot with what’s written in the post actually but in this case I think that htmx was not a good solution from the start if you knew you needed to manage complex states and rendering.
Re: Why Gumroad Didn't Choose Htmx
#37I literally only ever hear about htmx from YC. I still don't know what the point of it is, it seems like one of those opinionated programmer things like "I don't use a framework" or "you don't need javascript to make my site work"
It's for python programmers who think front-end is an unavoidable evil but wish to avoid it anyway.
Re: Why Gumroad Didn't Choose Htmx
#38> AI and Tooling Support: It’s worth noting that AI tools are intimately familiar with Next.js and not so much with htmx This is stated as a very matter-of-fact downside, but this is a pretty crazy portent for the future of dev tools / libraries / frameworks / languages. Predictions: - LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools - LLMs will encourage usage of open-source to…
And:
- developers will be incapable of writing or debugging code for development stacks or project types without LLMs trained on lots of matching examples
Re: Why Gumroad Didn't Choose Htmx
#39> AI and Tooling Support: It’s worth noting that AI tools are intimately familiar with Next.js and not so much with htmx This is stated as a very matter-of-fact downside, but this is a pretty crazy portent for the future of dev tools / libraries / frameworks / languages. Predictions: - LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools - LLMs will encourage usage of open-source to…
This will not be true for future frameworks, though it is likely true for current ones. Future frameworks will be designed for AI and enablement. There will be a reversal in convention-over-configuration. Explicit referencing and configuration allow models to make fewer assumptions with less training. All current models are trained on good and bad examples of existing frameworks. This is why asking an LLM to “code li…
I don't think convention over configuration causes LLMs any problems, GitHub copilot generates code matching rails conventions quite easily for example.
Re: Why Gumroad Didn't Choose Htmx
#40> AI and Tooling Support: It’s worth noting that AI tools are intimately familiar with Next.js and not so much with htmx This is stated as a very matter-of-fact downside, but this is a pretty crazy portent for the future of dev tools / libraries / frameworks / languages. Predictions: - LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools - LLMs will encourage usage of open-source to…
This will not be true for future frameworks, though it is likely true for current ones. Future frameworks will be designed for AI and enablement. There will be a reversal in convention-over-configuration. Explicit referencing and configuration allow models to make fewer assumptions with less training. All current models are trained on good and bad examples of existing frameworks. This is why asking an LLM to “code li…
But the new frameworks will never have anywhere near the amount of training data as established frameworks.