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

511–520 of 573 posts

Re: Hotwire: HTML over the Wire

#511

Post by 1_player »

voodootrucker wrote: post #472
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…

> The allure of xmlhttprequest was that over connections much slower than today As someone who implemented a SPA framework prior to "SPA" being a word much less React or Angular, I have to say for my company, it was all about state management. Distinguishing between web apps (true applications in the browser), and web pages (NYT, SEO, generally static content), state management was very hellish at the time (~2009). B…

I don't know about you, but "cookies, querystring parameters, server-side sessions, and form submissions" to me are an order of magnitude simpler, though dated and not very flexible, than any modern JS client-side state and persistency layer.

Re: Hotwire: HTML over the Wire

#512

Post by 1_player »

masa331 wrote: post #249
ketamine__ wrote: post #225

Earlier quoted context omitted.

I refresh SPA apps more than other apps because of these problems.

Me too. However, this also doesn't work properly on a lot of SPAs xD

Also the app looking fine immediately after refresh (when it's been server-side rendered), then crashes a second later when the JS framework hydrates the HTML and hits a client-side bug.

Re: Hotwire: HTML over the Wire

#513

Post by iamleppert »

I prefer to send updates to my web application as bitmaps. I do all the rendering of the HTML on the server to an image and just loop over the pixels and send a pixel if something changes from the last update. I call these updates “frames” and the client can even gracefully degrade — it can request a certain frame rate, or I can only send the luminosity value of a pixel, or randomly sample pixels to reduce detail for poor connections.

Re: Hotwire: HTML over the Wire

#514

Post by arvindamirtaa »

petee wrote: post #368
arvindamirtaa wrote: post #333

Earlier quoted context omitted.

Go ahead and load the hey login page. The js bundle your browser downloaded right there is the entire bundle for the whole email app. What size is it?

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.

Re: Hotwire: HTML over the Wire

#515

Post by nickjj »

sb8244 wrote: post #440
nickjj wrote: post #422

Earlier quoted context omitted.

> Fwiw, you can use long polling for LiveView if you wanted. How does that work for page transitions? The docs don't mention anything about this or how to configure it. With Turbolinks or Hotwire Turbo Drive, the user clicks the link to initiate a page transition and then the body of the page is swapped with the new content being served over HTTP. With Turbo Frames the same thing happens except it's only a designated…

It uses long polling over http. To be clear it's not restful http, but it's not websockets. I believe that Chris doesn't believe it's important for most people so there are no directions right now. Could be wrong there, I'm not Chris. Page changes are still initiated by the client in LiveView (although can be server initiated) LiveView is just channels under the hood. Once you consider that, long polling may seem mor…

> LiveView is just channels under the hood. Once you consider that, long polling may seem more obvious

It's not obvious to me for user invoked page transitions because when I think of long polling, I think of an automated time based mechanism that's responsible for making the request, not the user. But a page transition is invoked by the user at an undetermined amount of time / interval (it might happen 2 seconds after they load the page or 10 minutes).

Re: Hotwire: HTML over the Wire

#517

Post by vigneshacker »

arvindamirtaa wrote: post #314
yopo wrote: post #274

Earlier quoted context omitted.

Ya same here. I've been doing web dev for 13 years and was genuinely looking forward to this magical HTML only solution of theirs but left feeling deceived after finding out it's rails.

It's not rails. It's very specifically backend agnostic. Source: I've been using turbolinks and stimulus with Django for a good year and a half.

Hi, is it available in your public github repo?

Re: Hotwire: HTML over the Wire

#518

Post by sfusato »

nickjj wrote: post #515
sb8244 wrote: post #440

Earlier quoted context omitted.

It uses long polling over http. To be clear it's not restful http, but it's not websockets. I believe that Chris doesn't believe it's important for most people so there are no directions right now. Could be wrong there, I'm not Chris. Page changes are still initiated by the client in LiveView (although can be server initiated) LiveView is just channels under the hood. Once you consider that, long polling may seem mor…

> LiveView is just channels under the hood. Once you consider that, long polling may seem more obvious It's not obvious to me for user invoked page transitions because when I think of long polling, I think of an automated time based mechanism that's responsible for making the request, not the user. But a page transition is invoked by the user at an undetermined amount of time / interval (it might happen 2 seconds aft…

Your idea of "long polling" sounds more like periodic polling (repeated requests within a frequency), though that's not what long polling is or how it works.

Re: Hotwire: HTML over the Wire

#519

Post by snowl »

1_player wrote: post #511
voodootrucker wrote: post #472

Earlier quoted context omitted.

> The allure of xmlhttprequest was that over connections much slower than today As someone who implemented a SPA framework prior to "SPA" being a word much less React or Angular, I have to say for my company, it was all about state management. Distinguishing between web apps (true applications in the browser), and web pages (NYT, SEO, generally static content), state management was very hellish at the time (~2009). B…

I don't know about you, but "cookies, querystring parameters, server-side sessions, and form submissions" to me are an order of magnitude simpler, though dated and not very flexible, than any modern JS client-side state and persistency layer.

See: mobx

Re: Hotwire: HTML over the Wire

#520

Post by mosselman »

hadrien01 wrote: post #121
mosselman wrote: post #106

Earlier quoted context omitted.

This isn’t new at all. This is version 7 of Turbolinks that has been renamed to Turbo and has some added versions. It has been what the Ruby on Rails and it’s creator have promoted for years and years. The new thing about it are the name and associating it with Stimulus and some features, not the general concept.

Oh wow that is not clear at all. The old website of StimulusJS doesn’t redirect to its new home, and the old GitHub repo for turbolinks (not turbolinks-classic) still exists.

I had to look for it too. It isn’t clear and should’ve been. I’d like to know it is an enhanced renamed version of something I know rather than dismissing it because I can’t find time to learn something new.
Post reply on HN