561–570 of 573 posts
I wonder how long it will take before we reinvent SPAs? I like Hacker News in part because the tech is so boring. Server-side rendered, static HTML with a minimal amount of JS[0]. [0]: https://news.ycombinator.com/hn.js
Earlier quoted context omitted.
> But with LV wouldn't you need to create both a LV and a regular controller? That's a huge amount of code duplication. You just do LiveView instead of a regular controller. No duplication. When you request a page, it is render on the server and all of the HTML is returned over HTTP as usual. After the client has received the HTML updates, live updates can go over a websocket. For instance you start typing in a searc…
> You just do LiveView instead of a regular controller. No duplication. Yes but this is only in the happy case when the client is fully enhanced no? What happens if you hook up a phx click event to increment a like counter. After the page is loaded, if you click the + to increment it while having JavaScript disabled it's not going to do anything right? But with Hotwire Turbo, if you have a degraded client with no JS,…
In your Counter example, it's true that for the 'degraded' version to work, the link would have to be a proper link and not a phx-click. But in the (IMO very unlikely) case where this fallback is necessary, solving it with a proper link/route does not require duplication, just a different approach.
What you would do is create a LiveView that handles both the initial page and the 'increment' route. If LV is 'on', it intercepts the click and patches the page. if LV is 'off', your browser would request the 'increment' route, and the same LV would handle all this server-side and still display the new, incremented counter.
The LV is both the server-side controller /and/ the client-side logic. That's part of what makes it so appealing, but, admittedly, also something that can take a while to wrap your head around.
I've more than once reflexively gone for phx-click solutions where the LV would receive the event and 'do' something, only to later realize that it would be much better to use a proper url/routing solution (where LV is still the 'controller'). In hindsight it's often a case of treating LiveView too much like just 'React on the server', basically.
The downside is that this makes it really easy for developers to avoid making an actual API. The turbo frames _are_ the API. Great to bootstrap, but miserable if you ever want to implement a native mobile app (or any other client) on top of the same codebase.
Earlier quoted context omitted.
it might not be so bad 42 is not so many more bytes than... { counter: 42 } also - no massive up front JS bundles to contend with
Assuming that the counter state is on the client. A button with an event listener that runs x.innerHTML = state.counter++ makes a lot more sense than a round trip to the server. Just looked and Turbo is 135kb. I rewrote this website ( http://40.115.126.159/ ) with my own JS framework and it comes at 15kb, that's 9x smaller Turbo...
I think they actually mention adding Stimulus controllers in the demo video for those usecases.
Is this just PHP templating with extra steps?
You could just include it in your existing PHP app if you wanted to.
Earlier quoted context omitted.
Conventional wisdom is discrimination against privileged groups such as white men is less offensive because they’ve endured so much less of it. On one hand, it’s true. It’s part of white privilege which is tangible. On the other hand, however less often people in a privileged class are realistically impacted by discrimination, it’s still > 0.0%. Since it usually costs nothing more to include everyone it seems useful.…
So at first you're sympathising with discriminating against those that you see as suffering less and then your big idea is treating people equally and that's a 'hard sell'. That is like being a basic good fucking human, it's not a novel idea.
First, acknowledging the thinking behind a common opinion is not the same as sympathizing with it. It’s only stating a concept I disagree with.
Secondly, it’d be nice to take credit for this, big fucking idea, but unfortunately it’d be thousands of years too late. I explicitly mentioned the source.
Finally, I don’t see how it’s not a novel idea. If you started asking people to think kindly about rich Wall Street bankers or cable company executives would everyone he instantly on board?
I know those are extreme examples but that was the point of the story. What’s indeed not novel is to say, think well of all people.
The hard part is when you try to actually apply it equally, including to less popular but highly privileged classes of people.
I don’t claim that I can do it all the time, I’m sure I don’t in fact. However for any ideal shouldn't it be ok to try and work towards it over time?
Earlier quoted context omitted.
It's a productivity hack for companies that have more backend devs that strongly prefer ruby to javascript, like a presume basecamp team is... AFAIK this doesn't apply to the average web dev teams nowadays, most of whom never even used ruby before...
Yes funnily enough a Rails feature will only help those who code with Rails
Earlier quoted context omitted.
It's a productivity hack for companies that have more backend devs that strongly prefer ruby to javascript, like a presume basecamp team is... AFAIK this doesn't apply to the average web dev teams nowadays, most of whom never even used ruby before...
LiveWire on Laravel PHP LiveView on Phoniex Blazor on .Net
Earlier quoted context omitted.
49kB, and for the most part it's not executing, so what's your point? There is no reason that shouldn't be fast, regardless Not trying to stray too far from my original point, loading a small page with not alot going on should be fast. I'm not knocking Hey.com, I am just not going to pass out accolades for making a properly usable site!
I think you missed my point. That's not just the login page. That's the bundle for the entire app.
As others have noted, seems reasonably similar to LiveView, Livewire and Blazor. I’m somewhat bullish on these approaches - server side rendered monoliths (Rails, Django, etc.) are SO productive, at least for the first few years of development, but lack of interactivity is a big issue, and this solves it well. However, another big issue is the dominance of mobile. More and more, you’ve got 2-3 frontends (web and cros…
In the case of Rails if you're happy with a RESTfull API it handles serving different kinds content such as json pretty seamlessly via the respond_to method. i.e. if you want JSON ask for JSON if you want rendered html ask for that. However I think that for iOS they're still offering server side rendering via Turbo-iOS and Turbo-Android so you can build quickly and then replace that later if you need to.
This is one of the primary promises of MVC in the first place: views can be rendered independently of controllers and models. For a given controller method call, a view can be specified as a parameter.
In this case, swap "view" for JSON sent back over the wire...