[HN Gopher] Hotwire: A radical new old way to build web apps
___________________________________________________________________
Hotwire: A radical new old way to build web apps
Author : grzm
Score : 86 points
Date : 2021-01-28 15:07 UTC (7 hours ago)
(HTM) web link (delitescere.medium.com)
(TXT) w3m dump (delitescere.medium.com)
| agd wrote:
| I've been using Hotwire (turbo and stimulus) with my latest
| elixir/Phoenix project and it's been great.
|
| Adding dynamic behaviour to pages is quick and easy using the
| existing templating system. The stateless nature of it helps
| avoid bugs.
|
| If you _really_ need a very complex / dynamic UX then this isn't
| the way to go, but for everything else, I think it's much simpler
| than react etc.
| yumraj wrote:
| Why not just use Liveview since you're using Phoenix?
|
| Could you share your thoughts on the difference between
| Liveview and Hotwire.
| agd wrote:
| Liveview is stateful and uses websockets (or long polling)
| whereas turbo is stateless and uses regular http requests.
|
| NB. I haven't used liveview, however turbo seems much simpler
| on a conceptual level because of the lack of state. This
| comes with extra performance cost, but on my current project
| I'm optimising for dev productivity and simplicity.
| yumraj wrote:
| I'd be interested in the "how" if you'd consider creating a
| blog on using Hotwire with Phoenix.
|
| Or, if the source is in a public repo.
| nickjj wrote:
| > I'd be interested in the "how" if you'd consider
| creating a blog on using Hotwire with Phoenix.
|
| Technically it doesn't involve adding or changing even 1
| line of code on the back-end to make Turbo Drive and
| Frames work with any tech stack.
|
| It works out of the box by following Turbo's docs and
| using the HTML tags they mention along with bringing in
| the Turbo JS library.
|
| But for Frames you can optionally do what Rails does and
| add some server side code that says "hey, if this request
| is coming from a Turbo Frame only send the partial
| template as a response instead of the whole layout". That
| logic for Rails is here:
| https://github.com/hotwired/turbo-
| rails/blob/main/app/contro.... It's a nice to have
| optimization that will reduce your frame's HTML payload
| size but it still works without doing this.
|
| It can be ported to Phoenix or any back-end language by
| using a plug / middleware to not render the layout if a
| specific header exists in the request. The ETag stuff
| could be ported over too if your web framework's web
| server sets an ETag header.
|
| Streams are a bit more tricky to get working in other
| tech stacks since it may involve Websockets. Hopefully we
| start to see more examples in the future. But I believe
| it should be possible to pull off in a production ready
| way with any back-end language that has a good library or
| built in support for Websockets at the framework level.
| That means Flask, Django, Laravel and Phoenix are all
| good to go in this regard (probably others too but I'm
| not familiar enough with their ecosystems to say for
| sure).
| rackforms wrote:
| Id like to propose an alternative to the alternative posed in the
| article:
|
| Years ago I was tasked with building dozens of basic web forms.
| Immediately recognizing the inherit silliness of this task
| (boring, error prone etc), I built a form creation tool, which
| all these years later lives on as RackForms.
|
| Over the years the feature set grew organically to accommodate an
| ever growing set of demands. Yes we still build forms, but we
| also call into web services, display data, and so on.
|
| Point being, RackForms and any number of other form builders are
| the blindingly obvious choice for this task -- it would be down
| right silly to code forms by hand in this era.
|
| And yet that's what we do with the web as a whole.
|
| Once again Microsoft seems to have had the right idea in the good
| old Web Forms days. Instead of coding app's you'd simply drag and
| drop components and add wiring code to do what you needed.
|
| Sure it was never _that_ easy, but it 's really hard to see how
| it couldn't have been better given more time.
|
| Fast forward to today and as much as I adore say, VS Code, it's
| really nothing more than a hyper-powerful text editor. It has
| none of that tolling to allow for drag and drop development, Id
| propose that;s the real solution to this issue - Better Tooling.
| danpalmer wrote:
| That's great if you're building an internal tool, and in fact
| we use the Django Admin site for this, there exist low-code/no-
| code tools like Retool for things like this, it's a great type
| of solution.
|
| Where this breaks down is anything customer facing, like Hey
| (the product Hotwire was built for), Basecamp, or things like
| Thread the product I work on. These products aren't forms, or
| CMSs, and trying to fit them into those sorts of solutions
| results in a bad or counter-intuitive user experience, even if
| somewhere deep down these are essentially "CRUD" applications.
| Person5478 wrote:
| I've never seen anyone actually say MS got it RIGHT with
| webforms.
|
| Webforms was their attempt to bring the VB6 workflow onto the
| web and it was a terrible idea specifically because the web is
| not desktop.
|
| I get your point, but as far as I'm concerned any rationale
| that ends with the conclusion that MS got it right with
| webforms needs to be seriously reconsidered.
| jonstaab wrote:
| Maybe this would work for simple websites. But for web apps, it's
| a hard pass for me. For context, I write a web-based POS
| application, and waiting for a network request on every micro
| interaction is a no-go.
|
| There are lots of other problems with this approach that could be
| solved, but aren't immediately obvious, such as (similar to
| React) over-rendering. If someone has their focus in an input
| within the frame that gets swapped out, they're going to lose
| their focus. This has implications for accessibility as well as
| just regular usability.
| mattkevan wrote:
| Hey, the webapp Hotwire was extracted from isn't a webapp?
| cercatrova wrote:
| People say that Hey is definitely not as responsive as other
| client-side web apps like those made with React.
| leephillips wrote:
| Also see https://htmx.org/ for a library that progressively
| enhances web pages by getting HTML fragments from the server.
| donatzsky wrote:
| I was about to say that it sounds a lot like the same idea.
|
| Seems like Hotwire leans a bit more towards "SPA" territory.
| da39a3ee wrote:
| > after receiving HTML from the server, the browser
| asynchronously requested fragments of HTML to dynamically alter
| the parts of the page to change based on user interactions or
| events occuring on the server.
|
| It sounds like the quality of the resulting UX would be strongly
| inversely correlated with the server connection latency. On a bad
| connection, surely the SPA way is preferable? (i.e. many UI
| updates would require no AJAX)
|
| (I only read the first few paras and didn't really take in what
| Turbo is)
| parentheses wrote:
| Old way indeed. I always asked why this went out of fashion.
|
| JavaScript thrived under the reign of JSON.
| jack_riminton wrote:
| Nice to see it being used in frameworks other than Rails
|
| Would be great to see someone to do a rewrite of an SPA using
| Hotwire, haven't come across anyone making the switch yet
| propelol wrote:
| The Laravel (PHP) community is using Livewire, which is like
| Hotwire. Phoenix (Elixir) also have something called LiveView.
| francislavoie wrote:
| There are some pretty big key differences though. Livewire is
| pure ajax (at least for now, may change in the future, a
| rewrite is in the works), Hotwire is mostly websockets.
| Livewire does DOM diffing in the frontend, Hotwire does it
| server side (sorta? didn't dig a ton but that's my
| understanding). Performance characteristics are pretty wildly
| different depending on the usecase.
| sagolikasoppor wrote:
| With the advent of http3 won't normal ajax requests
| outperform websockets?
| jack_riminton wrote:
| The key test for me is whether a Rails/React site makes the
| leap. Perhaps the tech is just too new and therefore too
| risky
| kuon wrote:
| I use phoenix live views with immense success. This seems
| similar.
| jaywalk wrote:
| This is how the old ASP.NET Web Forms UpdatePanel worked.
| sputr wrote:
| And Drupal 7. What is old is new again. Laravel has also joined
| in on this train.
|
| But from what I remember ... I hated this technology with a
| burning passion back when I was still working on D7.
| PaulDavisThe1st wrote:
| was it actually different between D6 and D7 ?
| vyrotek wrote:
| Ha, oh boy. They were both magical and a nightmare when I
| worked with them years ago.
|
| One company I was at was adding more and more dynamic
| interactions to parts of their asp.net web app. It was a messy
| time trying to mix jQuery, ajax, update panels, and dealing
| with viewstate.
___________________________________________________________________
(page generated 2021-01-28 23:02 UTC)