Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hotwire: HTML over the Wire

hotwire.dev

Post reply on HN
Print view View original

501–510 of 573 posts

Re: Hotwire: HTML over the Wire

#501

Post by Lio »

yashap wrote: post #252

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.

Re: Hotwire: HTML over the Wire

#502

Post by Lio »

dharmab wrote: post #103
domano wrote: post #100

Earlier quoted context omitted.

Just wanted to point out that it is called duct tape, just to avoid misunderstandings since i had a similiar spelling error as a non-native speaker :)

This error is understandable as there is a popular brand of duct tape called Duck Tape.

...which is named after cotton-duck material tape once used for repairing ducts.

https://en.wikipedia.org/wiki/Cotton_duck

Re: Hotwire: HTML over the Wire

#503

Post by Lio »

philote wrote: post #238
fmakunbound wrote: post #186

Earlier quoted context omitted.

I’m glad this technique is making a comeback. The last 10 years of JavaScript on the client have been an utter shit show that left me wondering wtf people were thinking.

Same. And I'm still amazed that people loved JS so much they put it on the SERVER too! And now node/npm is everywhere.

Server side javascript was one of its original intended uses.

Here's the Netscape Enterprise Server manual from 1998[1]. Sorry I couldn't find an earlier version.

1. https://docs.oracle.com/cd/E19957-01/816-6410-10/816-6410-10...

Re: Hotwire: HTML over the Wire

#504

Post by luxcem »

echelon wrote: post #217
dasloop wrote: post #216

Earlier quoted context omitted.

Every time the pendulum returns, it returns profoundly changed. And it returns because the changes makes the coming back possible.

So when and how does the p2p / distributed pendulum swing back? When do we stop using AWS mainframes for everything? I sense that you're right about swings requiring change to older techniques. But I think there's also a component of being fed up with the direction things are currently facing.

Unfortunately p2p computing is hindered badly by the copyright industry. The research is still active and we have a lot of ideas for distributed computing and p2p for more than file exchange. A lot is used today to distribute a mainframe infrastructure instead of creating truely distributed network.

Re: Hotwire: HTML over the Wire

#505

Post by jack_riminton »

masa331 wrote: post #487
webmaven wrote: post #360

Okay this is a bit meta, but the whole cluster of "everything old is new again", "the pendulum of fashion has swung", "nothing new under the sun" takes is ignoring what tends to drive this sort of change: relative costs. The allure of xmlhttprequest was that over connections much slower than today, and with much less powerful desktop computers, a user didn't have to wait for the whole page to redownload and re-render…

I don't think app complexity and sophistication grew that much. Most of the problems common apps are solving can be dealt with standard CRUD-like interfaces and old boring tech and it works just fine. I think what drives this crazy train of overengineered solutions of SPAs and K8s for hosting single static page is deep separation of engineeres from the actual business problems and people they are trying to help. When…

Agree. The transformation of software into ever-smaller and more specialised 'ticketing' is as much a result of managerialism encroaching in. Basecamp have this bit in their Shape Up handbook about responsibility and how it affects their approach to software:

----------

Making teams responsible

Third, we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. This is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers.

Together, these concepts form a virtuous circle. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.

----------

Re: Hotwire: HTML over the Wire

#506

Post by jack_riminton »

jack_riminton wrote: post #345
ivanhoe wrote: post #195

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

Correction: this doesn't actually seem to be Rails specific at all

Re: Hotwire: HTML over the Wire

#507

Post by jstummbillig »

The crucial missing piece in this and LiveView, Livewire, etc is optimistic handling of client-side updates. It is not okay standard behaviour to have to wait a roundtrip to visually add a todo list item on the client.

Afaik Meteor is the only major full-stack framework handling this. Any other takers?

Re: Hotwire: HTML over the Wire

#508

Post by strzibny »

ZephyrBlu wrote: post #439
konha wrote: post #136

Earlier quoted context omitted.

It is. But he also wrote this in a subsequent tweet: > For a typically long running app like an email client, the obsession with shipping as little JavaScript as possible is actually detrimental to the end UX.

I'd argue that's almost objectively true. For a long running app, initial load time isn't as important as something like a ecommerce store.

Nope. And I will tell you why. To read my email I need the app to load. Gmail did not load for me in several countries and takes forever on a train wifi for example.

I never leave an email tab open, but even if I did, I first need it to load...

Re: Hotwire: HTML over the Wire

#509

Post by strzibny »

ashton314 wrote: post #125

Can someone familiar with this please diff it with Phoenix LiveView? https://github.com/phoenixframework/phoenix_live_view

LiveView does not need Redis, nor does it depend on any particular background job processing solution. It's plenty fast and minimal. On the other hand does not support or plan to support mobile use-cases. Others can chip in to expand on this ;).

Re: Hotwire: HTML over the Wire

#510

Post by habosa »

jstummbillig wrote: post #507

The crucial missing piece in this and LiveView, Livewire, etc is optimistic handling of client-side updates. It is not okay standard behaviour to have to wait a roundtrip to visually add a todo list item on the client. Afaik Meteor is the only major full-stack framework handling this. Any other takers?

This is a key point and I'd love to hear someone's thoughts on how you build an app with this framework that's snappy even on a high-latency connection.
Post reply on HN