211–220 of 224 posts
Earlier quoted context omitted.
This is a pipe dream. Browsers have come a long way but they're largely still broken in many many ways.
Would love to hear about which of those listed examples does not currently have native browser support.
Easy as pie. We don't even have to get into the specific of making things work correctly.
Earlier quoted context omitted.
Would love to hear about which of those listed examples does not currently have native browser support.
> what the user is currently typing Easy as pie. We don't even have to get into the specific of making things work correctly.
Earlier quoted context omitted.
Which is why you use git command line for such tasks
Where you can put comments on problematic lines/blocks of code easily with the git command... (Please continue, I'm really curious of there are better ways than what I'm currently doing)
Earlier quoted context omitted.
What advantages does HTMX have? You end up with splintered spaghetti code, multiple languages/idioms, and unpredictable state.
* spaghetti or not depends on how you structure things, not on the framework/library used. * HTMX doesn’t introduce a new language. It extends HTML with props, which is less than what React is doing. * unpredictable state? You rely on the browser and (partial) page-refreshes.
Earlier quoted context omitted.
> Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. I have no idea if that's accurate, but let's assume for a moment that it is. - Vue supports JSX, but it is not the default. - Angular does not support JSX. - Svelte, which you neglected to mention, does not support JSX. - Solid does indeed use JSX, as of course does React. So two out of the five main…
I listed frameworks that makes majority of the market share that are based on JSX and react-like reconciliation loop. This architecture is also now dominate in the mobile apps space via React Native and Flutter as well. So I am not sure what you're talking about. The industry has largely stabilised on this architecture because it works. So I don't know who this "we" you're talking about or what you're even talking ab…
If you want to move the goalposts to suit your argument, go right ahead; I won't be participating.
Earlier quoted context omitted.
> loading times What does React have to do with loading times of a page? React does not contribute to that at all other than having to download the JS runtime, which with Preact is 3KB. > You cannot argue that React is extremely heavy and also adds a lot of time between first render Yes you can! In no world would React itself add enough render time to make people navigate back, even if running on a computer from the…
React itself, or Preact for that matter, is just the baseline. You still need the application itself, which in every application I’ve worked on is quite a bit bigger than the framework itself. So you need to download the app, maybe have that app perform some fetch requests, then have the app generate html to show to the user. This is going to be slower than just retriving the resulting html directly. If you’re in a p…
That's why most client-side routing libraries support lazy loading. You don't have to load the entire application at once, only the parts you need.
> So you need to download the app, maybe have that app perform some fetch requests
That's... completely unrelated to React, though? Parent comment claimed that React is slow and HTMX fast - does HTMX make fetches magically faster or what?
Earlier quoted context omitted.
No worse thing for ux as the infinite scroll. As it breaks the native cmd-f/ctrl-f page search and makes loading progressively slow.
It doesn't do such thing at all, unless you think it's acceptable to load EVERYTHING in HTML, hide it, and do front-end search. Which would be completely nuts to do for things where infinite scroll is used.
Another example is filtered goods at the local electronics store webfront. Progressive loading without ability to go directly to page 7 wastes my time if I know that what I need is there as each load of 10 items takes time. But of course this pattern increases some shitty OKR in time-spent-on-website. Hate this.
Earlier quoted context omitted.
> what the user is currently typing Easy as pie. We don't even have to get into the specific of making things work correctly.
I don't understand what is broken with the browser's management of typed content. Do you have an example of UX that requires a custom state management layer on top?
Input management is one of the most difficult aspects of web development once you want anything beyond a simple input. That you have to ask for an example means this conversation isn't going anywhere. Good luck!
Earlier quoted context omitted.
Because "simple" is transient at best and a lie at worst. But for more details, see the sibling comment: https://news.ycombinator.com/item?id=49069477
Most webapps out there will never need the level of complexity of SPA frameworks. They will work completely fine for the foreseeable future with something like htmx. The GitHub notifications update bug is more of an eventual consistency issue than a ‘forgetting to update the UI’ issue.