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

471–480 of 573 posts

Re: Hotwire: HTML over the Wire

#471

Post by IggleSniggle »

deergomoo wrote: post #315
vasachi wrote: post #130

Earlier quoted context omitted.

Huh? How does SPA help here? JSON payloads don't go faster over the wire than html.

Surely a JSON payload is almost always going to be considerably smaller than the contents of that payload laid out in an entire HTML document?

It’s not the entire HTML document, it’s piecemeal. As for sizing equivalent data in HTML vs js, I remember reading an investigation that XML and JSON are generally closer than you would expect and that for some data structures, XML is terser.

Re: Hotwire: HTML over the Wire

#472

Post by voodootrucker »

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).

Before that, pages were entirely server rendered, and JavaScript was so terrible thanks to IE and a single error message (null is null or not an object) that it was deemed insanity to use it for anything more than form validation.

However, with the advent of V8, it became apparent as an ASP.NET developer that a bad language executing at JIT speeds on the browser was "good enough" to not send state back and forth through a very complex mesh of cookies, querystring parameters, server-side sessions, and form submissions.

If state could be kept in one place, that more than justified shifting all the logic to the client for complex apps.

Re: Hotwire: HTML over the Wire

#473

Post by ksec »

cyrialize wrote: post #261
sourc3 wrote: post #120

This 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…

I completely agree with this. For reference, I'm a relatively new developer - 3.5+ years of experience in my first developer position. At the beginning of college everyone was SUPER into NoSQL. All my friends were using it, SQL was slow, etc. Nearing the end of college and the beginning of my job I began seeing articles saying why NoSQL wasn't the best, why SQL is good for some things over NoSQL, etc. Technology is c…

You should be very glad you saw the utter pile of crap in technology fashion show at such a young age.

Re: Hotwire: HTML over the Wire

#474

Post by stevenhuang »

codethief wrote: post #272

In case anyone from Basecamp sees this thread: The introductory video is far too long, far too technical (I know a lot about web dev but don't know a lick of Ruby or Rails) and far too fast to follow. I was really interested in Hotwire because of the comments here and now… not so much anymore. (Which of course doesn't say anything about the quality of the tech. I just thought I'd post my first impression of the websi…

Really? Well I'll be one to chime in that I found it perfectly follow-able and was able to get a quick high level understanding of what this is.

Re: Hotwire: HTML over the Wire

#476

Post by ksec »

freedomben wrote: post #148
1f60c wrote: post #123

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

I also prefer boring and love how HN works. That said though, modern consumers expect much more. We tech people like command lines, the ultimate in simple and boring. Modern consumers often want animation and things[1]. Source: UI/UX researchers tell me this when I push back and say "let's keep the tech simple and forgo some of the animations, etc in the name of using simple OOTB stuff without hacking thousands of li…

>UI/UX researchers

Is that with respect to Web Page / Tech?

Because people expect different things for Apps and WebPages.

Re: Hotwire: HTML over the Wire

#477

Post by est »

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…

> If state could be kept in one place, that more than justified shifting all the logic to the client for complex apps.

Reminds me of saving Rich Text content on the server side. It was nightmare.

Also reminds me of the Microsoft RTF format. It's basically a memory dump of the GUI editor.

The state binded on a tree was never a good idea to start with.

Re: Hotwire: HTML over the Wire

#478

Post by ksec »

ivanhoe wrote: post #195
jack_riminton wrote: post #145

Most of the comments here are along the lines of: this is old tech! But this isn’t really about the tech, it as much a productivity hack that allows people to be much closer to that old fashioned concept of a full stack developer This is what has allowed Basecamp to create Hey with a team just a fraction of the size of their competitors

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

Re: Hotwire: HTML over the Wire

#480

Post by spentu »

qudat wrote: post #459
Trasmatta wrote: post #300

Earlier quoted context omitted.

No, the argument has never been "replace all JS with static HTML/CSS". The argument is "JavaScript frontends are becoming unnecessarily bloated, slow, and complicated, and we can do better". Solutions like the one Basecamp is proposing with Hotwire include pushing as much rendering logic as possible to the server, where you're using a language like Ruby for logic. Nobody thinks you can just remove all logic from a we…

“Bloated.” This is actually the opposite. Go into a language like python and install numpy (30mb) and then come back to complain to me about a 2mb js bundle. This argument is so bogus if you look at alternative language dependency sizes.

While there are issues within Python side, I think it is quite unfair to use numpy as an example.

My reasoning is that the numpy project is meant for scientific and prototyping purposes, but many times people are using it as an shortcut and include the whole thing into their project.

That being said, the quality in these packages does vary depending on who developed them. But I think this is a problem that exists with all languages where publishing packages is relatively straightforward.

Post reply on HN