Hehe. I did exactly this in Twisted Woven LivePage in around 2002.
Hotwire: HTML over the Wire
351–360 of 573 posts
Re: Hotwire: HTML over the Wire
#352This is so exciting to see, especially for older folk like me. Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery. However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we ar…
The Rails people never went for SPAs though. Releasing another server-rendering AJAX thing for rails (previous was TurboLinks) no more represents "the pendulum swinging back" than a new version of COBOL that runs on mainframes represents the pendulum swinging back to mainframes. If this approach gains market share against React etc., then that will be meaningful - but don't hold your breath, there are legitimate reas…
I don't think that's entirely accurate. Lots of Rails users went the SPA route the second stuff like Backbone came out. Wycats was big in the Rails community at this time and he spearheaded Emberjs. The Shopify guys were (and are still) big in the Rails community and they created their own Batman.js. It's just that the Rails core devs made a decision to not go that route. They were even working on their own front end framework at one point and after some time they decided to kill it in favor of just using pjax/turbolinks. You can get your 80% case accomplished with these technologies with substantially less effort. There are definitely reasons to go SPA, but the dev community at large has jumped on the hype train here without really identifying that using these technologies are a good idea for their use case. I mean, there's a lot of people doing CRUD with React. That's crazy.
Re: Hotwire: HTML over the Wire
#353Earlier 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.
Node has a better runtime than ruby or python, so why not? and you also have TS.
Re: Hotwire: HTML over the Wire
#354Isn't this replacing the complexities of JS libraries like react/redux-saga with the complexities of these new server-side libraries..? Reduced bundle size looks like a big advantage & this will hopefully encourage the adoption of lighter front-end tech like preact/inferno/svelte. But the downside seems to be more resource consumption on the back-end, especially if using websockets, and so higher cost & more vulnerability to a DDOS? Also, what about offline support?
Re: Hotwire: HTML over the Wire
#355Earlier quoted context omitted.
It did if you used XMLHttpRequest.
If you type a chat message in your browser, how does it automatically show up in my browser with XMLHttpRequest?
Long Polling is how we used to do it. The web page opens a request to the server but the server does not reply. Once the event happens on the server, the server replies to the old request and the client opens a new request.
Re: Hotwire: HTML over the Wire
#356Earlier quoted context omitted.
It did if you used XMLHttpRequest.
If you type a chat message in your browser, how does it automatically show up in my browser with XMLHttpRequest?
I think in Netscape 4 you could also make a request in an iframe which the server responded to with Content-Type: application/javascript and Transfer-Encoding: chunked. Then every time the server got an event it would write one chunk of javascript, which the client would execute immediately. This script could then call a callback in the parent frame.
Re: Hotwire: HTML over the Wire
#357Earlier quoted context omitted.
Between what? Your frontend is serving the html/css/js, that's your frontend. You can have another background service behind it, as many layers as you want. This separation doesn't have to be at the http level.
Let's say you take another approach. Build a backend that serves REST, GraphQL or whatever protocol. This can be a Rails backend, could be Python, JS, whatever. Now you or the frontend team are free to build the frontend with whatever technology. You can update it more freely to shining new JS frameworks because it is not entirely tied to your backend. Also, if your client/boss asks you to build a native IOS frontend…
[deleted]
Re: Hotwire: HTML over the Wire
#358Earlier quoted context omitted.
I'm not a front end engineer, but it always seemed crazy to me. I remember testing out the Google Web Toolkit when it came out more than a decade ago, and the craziest thing about it to me wasn't the Java --> JavaScript compilation, it was that the server just dumped an empty page and filled everything in with JavaScript on the client. Then, remember the awful awful #! URLs? Atrocious, and seemed like obviously a ter…
AWS used to rely on JWT for their consoles (haven't for a few years now, most folks migrated away some 5 years ago) It's why they used to be horrendously bloated with large javascript bundles that took so long to process on the client side. Roughly speaking the idea was "We don't have any Javascript developers, but we do have Java developers. JWT allows us to bridge that divide". Neat in theory, and an understandable…
I believe you mean “GWT” and not “JWT”.
Re: Hotwire: HTML over the Wire
#359Earlier 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.
I think it's less about loving JS so much, and more about not having any options on the client. If there were any better client options they might have won!
Re: Hotwire: HTML over the Wire
#360Okay 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 (one can argue that focusing on better HTTP caching on the server and client might have been smarter) after every single user interaction. This was also much of the draw of using frames (which were also attractive for some front-end design use-cases later re-solved with CSS).
As apps got more complex, clients got more compute, bandwidth grew, and as web audiences grew, offloadingl much of the page rendering to the client helped to both contain server-side costs and increase or maintain responsiveness to user interactions.
Now, as desktop client performance improvement slows down (this isn't just the slowing of computer speeds, computers are also replaced less frequently), average bandwidth continues to grow, app complexity and sophistication continues to grow, but as server compute cost falls faster than audience size grows, shifting rendering to HTML back to the server and sending more verbose pre-rendered HTML fragments over the wire can make sense as a way of giving users a better experience.