4 ms·

I'm sorry, but these arguments are so tired. > SPAs have allowed engineers to create some great web applications, but they come with a cost: > Hugely increase

by nawgz 3y ago

I'm sorry, but these arguments are so tired. > SPAs have allowed engineers to create some great web applications, but they come with a cost: > Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks. Yes, better quality software usually packages a bit more complexity. SPAs are popular, just like native apps, because people don't like jarring reloads. Webviews in native apps are panned for a reason; turning your whole app into a series of webviews would be stupid, right? > Tooling is an ever-shifting landscape in terms of building and packaging code. I've used these 4 libraries to build apps since 2015: * React * MobX * D3 * Webpack The only one I have had pain with is react-router-dom, which has had 2 or 3 "fuck our last approach" refactors in this time. And I added TypeScript in 2018. PEBCAK > Managing state on both the client and server It's a lie that a thin client isn't managing state; it's just doing a static, dumb job of it. Imagine some cool feature like... collaborative editing. How would you pull that off in HTMX? > Frameworks, on top of libraries, on top of other libraries, on top of polyfills. React even recommend using a framework on top of their tech: Yes, React is famously not a batteries-included library, while Angular is. But, as addressed, you need about 3 other libraries. Besides, did you know: HTMX is also a framework. Did you know: HTMX also has a learning curve. Did you know: HTMX forces you to be able to manipulate and assemble HTMLstrings in a language that might not have any typing or tooling for that? Anyways, I've said enough. I should've just said what I really think: someone who can't even get their nested HTML lists to actually indent the nesting shouldn't give advice on building UIs.

traverseda 3y ago
>Imagine some cool feature like... collaborative editing. What are you gaining by writing something like that in java/type-script rather than like rust and webassembly? To me javascript is in a sort of uncanny valley where you probably want to be either making a real app and compiling it to wasm or using something like htmx.
- nawgz 3y ago
  > rather than like rust and webassembly WASM can't even interact with the DOM, how exactly are these languages positioned better to give me access to a ton of UI primitives? The backend can be a fast language, certainly, but the browser is a premier UI platform... and it's powered by JS... To me, Rust developers thinking they know how to build UIs is the real uncanny valley. What they produce looks like it should work, but the more you look at it, the more you realize they don't know what UX stands for
vb-8448 3y ago
> Imagine some cool feature like... collaborative editing. In my opinion, the whole point of the article and for everyone who is backing htmx is that SPA frameworks are too complex (and a liability) for solo/small teams or projects that don't need `collaborative editing`(or other advanced stuff).
- nawgz 3y ago
  > In my opinion, the whole point of the article Well, in my opinion, the article claims "HTMX is the future" as its title, and so it's impossible to interpret the arguments in any other way than "the user experience benefits of the SPA might matter to the users, but I think it's stupid because I dislike JS"
  - CRConrad 3y ago
    > Well, in my opinion, the article claims "HTMX is the future" as its title, Titles are by necessity summary in nature. If you want the whole complexity and nuance of the article in the title, the whole article would have to be the title. It's a bit too long for that. (And then everyone would complain that there was no additional meat to the body text.) > and so it's impossible to interpret the arguments in any other way than "the user experience benefits of the SPA might matter to the users, but I think it's stupid because I dislike JS" No, sorry, that's BS: It's eminently possible to interpret the arguments differently. All you have to take into account is that a less abbreviated (and frankly still a bit too long) version of the title could have been "HTMX is the future for solo/small teams or projects that don't need `collaborative editing`(or other advanced stuff)". HTH!
    - nawgz 3y ago
      > Titles are by necessity summary in nature Ok, that's why I made arguments against the body of the text. Did you read my initial post? I'm sure you must've, which makes it so strange you'd come attack this argument while pretending that the other ones don't exist > It's eminently possible to interpret the arguments differently. It's really not. The whole thing is a series of strawmans aiming to justify degrading user experience to avoid developer "complexity", but then that developer complexity is grossly overstated, as if from someone who has never dipped their toe in it decided that each complaint they had heard about it was spoken by God himself. Indeed, my whole first comment is thoroughly discarding each of these strawmans before I grew frustrated by the fact that the author and the thread were both reciting this 2015-era anti-JS dogma. I suggest you go try to make counterarguments to those points instead of my exasperated reply to someone adding nothing to the convo. HTH!
rmbyrro 3y ago
> _Yes, better quality software usually packages a bit more complexity._ That view (+quality = +complexity) is actually flip sided, isn't it? [1] [1] https://www.infoq.com/news/2014/10/complexity-software-quality/ https://www.infoq.com/news/2014/10/complexity-software-quali...
- nawgz 3y ago
  Sure, with respect to a fixed problem I agree. With respect to static rendering vs building an application state machine, though, the problem isn’t fixed, and inherently has more complexity

by nawgz 3y ago

traverseda 3y ago

>Imagine some cool feature like... collaborative editing. What are you gaining by writing something like that in java/type-script rather than like rust and webassembly? To me javascript is in a sort of uncanny valley where you probably want to be either making a real app and compiling it to wasm or using something like htmx.

nawgz 3y ago
> rather than like rust and webassembly WASM can't even interact with the DOM, how exactly are these languages positioned better to give me access to a ton of UI primitives? The backend can be a fast language, certainly, but the browser is a premier UI platform... and it's powered by JS... To me, Rust developers thinking they know how to build UIs is the real uncanny valley. What they produce looks like it should work, but the more you look at it, the more you realize they don't know what UX stands for

vb-8448 3y ago

> Imagine some cool feature like... collaborative editing. In my opinion, the whole point of the article and for everyone who is backing htmx is that SPA frameworks are too complex (and a liability) for solo/small teams or projects that don't need `collaborative editing`(or other advanced stuff).

nawgz 3y ago
> In my opinion, the whole point of the article Well, in my opinion, the article claims "HTMX is the future" as its title, and so it's impossible to interpret the arguments in any other way than "the user experience benefits of the SPA might matter to the users, but I think it's stupid because I dislike JS"
- CRConrad 3y ago
  > Well, in my opinion, the article claims "HTMX is the future" as its title, Titles are by necessity summary in nature. If you want the whole complexity and nuance of the article in the title, the whole article would have to be the title. It's a bit too long for that. (And then everyone would complain that there was no additional meat to the body text.) > and so it's impossible to interpret the arguments in any other way than "the user experience benefits of the SPA might matter to the users, but I think it's stupid because I dislike JS" No, sorry, that's BS: It's eminently possible to interpret the arguments differently. All you have to take into account is that a less abbreviated (and frankly still a bit too long) version of the title could have been "HTMX is the future for solo/small teams or projects that don't need `collaborative editing`(or other advanced stuff)". HTH!
  - nawgz 3y ago
    > Titles are by necessity summary in nature Ok, that's why I made arguments against the body of the text. Did you read my initial post? I'm sure you must've, which makes it so strange you'd come attack this argument while pretending that the other ones don't exist > It's eminently possible to interpret the arguments differently. It's really not. The whole thing is a series of strawmans aiming to justify degrading user experience to avoid developer "complexity", but then that developer complexity is grossly overstated, as if from someone who has never dipped their toe in it decided that each complaint they had heard about it was spoken by God himself. Indeed, my whole first comment is thoroughly discarding each of these strawmans before I grew frustrated by the fact that the author and the thread were both reciting this 2015-era anti-JS dogma. I suggest you go try to make counterarguments to those points instead of my exasperated reply to someone adding nothing to the convo. HTH!

rmbyrro 3y ago

> _Yes, better quality software usually packages a bit more complexity._ That view (+quality = +complexity) is actually flip sided, isn't it? [1] [1] https://www.infoq.com/news/2014/10/complexity-software-quality/ https://www.infoq.com/news/2014/10/complexity-software-quali...

nawgz 3y ago
Sure, with respect to a fixed problem I agree. With respect to static rendering vs building an application state machine, though, the problem isn’t fixed, and inherently has more complexity