81–90 of 93 posts
Does python have anything like this?
A lot of people have much worse ping times than that. Try using this on a satellite connection for example, and your experience won't be very pleasant.
On my internet connection, which is pretty average by polish standards, the best ping I can get is 30ms, and that only happens when the server I ping is just one or two hops away. I probably won't be able to go under 100ms when the server is in the US.
It seems like this approach sacrifices runtime performance for development speed. I feel like it might often be a good tradeoff to make, but it's a tradeoff nevertheless, and we should recognize that. Separate layers for frontend and backend introduce complexity, but client side code is client side code, you can't go much faster than that.
Wish I had the time to really study Phoenix's LiveView and implement the same in Java. AFAIK there's no equivalent for this in Java and I mean the same not kinda-the-same but not really like Vaadin or God forbid GWT.
Good luck. Liveview depends strongly on features of the erlang VM that you won't get right without a deeper understanding of erlang (how do you clean up a websocket connection when the actor exits early, say due to throwing an exception - that's zero lines of code in lv), you're probably better of taking inspiration and writing it from scratch.
I hope their form validation demo is just a toy and not an actual example of real email validation code, because it doesn't handle '+' in the localpart, which is a very commonly used character. I don't see any custom validation code in the demo source, though, so it kind of looks like they have a builtin "email" validator that's broken, which makes me question the production-readiness of this thing.
As someone who has barely done any web development in his life but having a fairly interactive side project in mind I wanted to work on, is Rails and StimulusReflex a solid thing to start out with right now, or would you recommend just going with React, Vue and so on? Navigating all those frameworks seems very complex.
It's 500ms to 1000ms for something that ought to be instantaneous like clicking on a tab that I have already seen.
React websites might be a larger initial download, but its only an extra 3 seconds wait to begin with, then near instant reactivity afterwards for everything that doesn't require a network call.
Ironically, the browser cache is much faster than 500ms so the tab demo would have been faster if implemented as a full page refresh.
A tiny payload from the world's slowest backend framework. The Rails community has spent years resisting the future. Ember was an attempt to jam Rails into JavaScript and it's been a miserable, confusing, slow mess that every team utterly regrets. Rails has spent years and years pushing server-side rendered partials. Now the Rails community has yet another "new" approach that involves writing yet more Ruby instead of…
So they like writing more Ruby instead of JavaScript. They've enjoyed Rails pushing server-side rendered partials.
And the person that comes demanding they rewrite all their frontend in the current JS framework-du-jour (possibly to be rewritten again in a couple of years) will be told to fuck right off.
Earlier quoted context omitted.
Good luck. Liveview depends strongly on features of the erlang VM that you won't get right without a deeper understanding of erlang (how do you clean up a websocket connection when the actor exits early, say due to throwing an exception - that's zero lines of code in lv), you're probably better of taking inspiration and writing it from scratch.
So in your opinion in Java land resources are always leaked when some exception occurs? That’s a bit far from the truth
Whereas with Elixir, it's handled by the way failed processes are handled which is to just "let it die". Another one will come along and replace it. (I'm greatly simplifying here)
A tiny payload from the world's slowest backend framework. The Rails community has spent years resisting the future. Ember was an attempt to jam Rails into JavaScript and it's been a miserable, confusing, slow mess that every team utterly regrets. Rails has spent years and years pushing server-side rendered partials. Now the Rails community has yet another "new" approach that involves writing yet more Ruby instead of…
Imagine that there are companies (like the one I work for) and projects that are absolutely NOT going to scale (maybe because they're somebody else's internal apps, which is what I do) and the company behind them will not have trouble hiring JS developers, because they're a Ruby shop. So they like writing more Ruby instead of JavaScript. They've enjoyed Rails pushing server-side rendered partials. And the person that…
But we still have the requirement of "near instant" front-end for certain things. And this is precisely the sort of thing that a team of RoR devs can really get behind and do well. Rather than try and cram yet another JS paradigm and DSL into their heads only to be forgotten when the next one rolls into town.
Personally I'm a Phoenix/LiveView champion, but we're a Rails shop and I know better than attempt The Big Rewrite. So this really fits the bill.