41–50 of 93 posts
I appreciate the work put into this, glad to see SPA alternatives and can understand using this for existing Rails projects. I'm curious why would one would choose this over Phoenix LiveView for a new project? How are the two different?
Moving everything to the server instead also closes the gap, but the obvious problem is that this introduces a lot of latency for UI interactions. Ajax page loads/Turbolinks works so well because it actually makes things faster with almost zero effort. Introducing a similar method for every UI interaction though is a different matter, and I don't see how the latency won't be noticeable.
For instance, The TodoMVC example's server seems to be far enough way from my location that creating a task has noticeable lag. Sure it's just an example, but without introducing some client-side/optimistic rendering, that's going to be hard to avoid (and that would defeat the purpose of having all your logic in one place, on the server). Not sure how this is addressed here?
In many ways, this is very cool. But, I have to admit, I don't love it. I would love to have an integrated environment where client/server doesn't matter, but I don't think this gets far enough. Working in a spread of html.erb with special tags plus some Javascript doesn't feel great to me compared to React. I like their TodoMVC app, since that gives a simple, minimal starting point. Getting persistence in that few l…
TodoMVC is meant to be a minimalist demo, not a battle-hardened app.
We switched from React to Reflex 7 months ago. We have fewer bugs than we did with React, and we ship things about 3 times faster.
5/5 of us strongly prefer Reflex over React. Including one of us who was a big React aficionado beforehand.
Just wanted to put that out there for anyone considering Reflex, a bug in TodoMVC is not a harbinger of a bad framework.
Now that Google will index SPAs, I'd strongly consider a SPA where the server just generates meta tags (for SoMe link previews etc)
Closing the gap between server and client in terms of app development is definitely the answer. Also agree with the pitch that the currently popular approach of simply moving everything to the client has made tooling incredibly complex (although it's getting better). It's great to see new tools like this being built. Moving everything to the server instead also closes the gap, but the obvious problem is that this int…
As for latency, this is over websockets. It becomes a problem if you are connecting to a server across the ocean but otherwise, it's incredibly fast and feels just as snappy as JS. I actually also haven't used Stimulus Reflex, just Phoenix LiveView so I'm not sure if they are exactly the same, but the TL;DR is that they are sending VERY tiny payloads over websockets. This video explains it well (though it's also a demo of LiveView): https://www.youtube.com/watch?v=MZvmYaFkNJI
Closing the gap between server and client in terms of app development is definitely the answer. Also agree with the pitch that the currently popular approach of simply moving everything to the client has made tooling incredibly complex (although it's getting better). It's great to see new tools like this being built. Moving everything to the server instead also closes the gap, but the obvious problem is that this int…
[1] https://dockyard.com/blog/2020/12/21/optimizing-user-experie...
[2] https://changelog.com/posts/petal-the-end-to-end-web-stack
Does python have anything like this?
In many ways, this is very cool. But, I have to admit, I don't love it. I would love to have an integrated environment where client/server doesn't matter, but I don't think this gets far enough. Working in a spread of html.erb with special tags plus some Javascript doesn't feel great to me compared to React. I like their TodoMVC app, since that gives a simple, minimal starting point. Getting persistence in that few l…
Here comes the classic HN middle-brow dismissal :) TodoMVC is meant to be a minimalist demo, not a battle-hardened app. We switched from React to Reflex 7 months ago. We have fewer bugs than we did with React, and we ship things about 3 times faster. 5/5 of us strongly prefer Reflex over React. Including one of us who was a big React aficionado beforehand. Just wanted to put that out there for anyone considering Refl…
Personally, I enjoy React on the front-end but don't currently like any back-end framework, so Reflux may well be better in aggregate.
(FWIW, I have a PhD in computer science and big part of that was on web applications and frameworks for them, combined with ~15 years commercial experience mastering web development, so this wasn't meant to be a middle-brow dismissal. As I said, it is exciting, I'm just not convinced.
I think there is some merit in the argument that too much cleverness can be dangerous. Battle-hardened is tricky; I agree TodoMVC is meant to be a minimalist demo, but if a minimal demo can have subtle bugs caused by the cleverness of the data binding, how much more so a real app with a much more complex data model?
But I guess it does eliminate whole other classes of bug, so I can believe it works less buggy and more productive better than React+some back end.
I certainly find the current front/back split endlessly painful. I am also excited by the new React Server Components which might be another good solution to that.)
EDIT TO ADD: I guess what I was trying to say is: I found this interesting, and I looked at it, and then I found this bug in the example, and I wonder if this framework might make a bug like that more likely because the power of making some things easier is obscuring what is happening in some cases, and I don't know if that trade-off is worth it.