Live data from Hacker News

Hotwire: HTML over the Wire

hotwire.dev

401–410 of 573 posts

Re: Hotwire: HTML over the Wire

#401
post #260

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

Hashbang URLs are gone because of the PushState API, not because people have given up on the idea.

Hashbangs preclude even the option of the server even seeing the state that the client wants from the first request, necessitating severa hops. PushState, though it allows URL transitions without a full reload, is an entirely better and different idea.

Re: Hotwire: HTML over the Wire

#402

Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile…

I agree with this. My favourite thing about the web is reading content with links to other content

Wikipedia is a great example of a perfect web site: simply presented content linked together in a way that encourages exploration

People keep hijacking this experience to make it "better" or more like an "app" but that detracts from what makes the web so magical

Re: Hotwire: HTML over the Wire

#403

Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile…

Best of luck getting paying users to install each individual desktop application, as opposed to installing a browser and then navigating to multiple applications without any additional desktop/native work.

I guess there might be space for something like Steam, but for business apps, but I just don't see it. The argument "This isn't what the web was made for" is kind of a cowpath argument. The web is being used to (among other things) browse applications. Whether or not that's what anyone planned is irrelevant. That's what's happening right now.

I think it's fair to suggest paths forward that both accommodate users and also bring sanity, but tagging every attempt at progressing applications-in-browser as "Square peg, round hole, need native app" just totally dismisses most of the users these applications are trying to capture.

Re: Hotwire: HTML over the Wire

#404
post #102

amazing. This used to be called /cgi-bin/ with templates and XMLHttpRequest (a Microsoft invention initially supported only in IE then adopted by everyone) and now it's suddenly a new technology/approach but with a new name so you're not ridiculed for using it? I gotta give them credit for revisiting server-side page assembling though; moving application logic and templating mostly to the front end was a HUGE mistake…

cgi-bin didn’t give you the ability to update a chat page across several different windows in near real-time.

in no way elegant, but yes, with js, it's possible with netscape 3 and up, possibly with 2.

html, http, js, css are pretty thorough in their design, and it shows.

all the features described here are possible without any frameworks, this is merely a much easier way to build it than from scratch.

Re: Hotwire: HTML over the Wire

#406

Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile…

Best of luck getting paying users to install each individual desktop application, as opposed to installing a browser and then navigating to multiple applications without any additional desktop/native work. I guess there might be space for something like Steam, but for business apps, but I just don't see it. The argument "This isn't what the web was made for" is kind of a cowpath argument. The web is being used to (am…

People are installing apps for "everything" on mobile. Even for stuff where a web page exists and is fully sufficient.

The rest is just: "But with a big enough hammer we get the square peg into the round hole, so what's wrong with that? People are doing that the whole time. Seems fine".

Re: Hotwire: HTML over the Wire

#407

Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile…

So what? Modern web browsers turned out to be a great application runtime and the Web turned out to be a great delivery platform. Nowhere else in software engineering would you see so much resistance to a perfectly good tool.

Maybe the problem is that it's too good: people and organizations end up producing "web applications" instead of "web sites" just because the technology is so readily available and so widespread.

If there's one thing to complain about, it's that sites don't gracefully degrade when JS is disabled. I don't care that your browser game doesn't work without JS, but I do care quite a bit that I can't read blogs, news websites, etc.

Re: Hotwire: HTML over the Wire

#408

Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile…

I agree with this. My favourite thing about the web is reading content with links to other content Wikipedia is a great example of a perfect web site: simply presented content linked together in a way that encourages exploration People keep hijacking this experience to make it "better" or more like an "app" but that detracts from what makes the web so magical

Even if Wikipedia had some interactive content (to explore some topics by playing around with stuff) it would be still fine.

I'm not arguing against "interactive documents". I'm arguing that "the web" is not for full blown applications.

Re: Hotwire: HTML over the Wire

#409

Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile…

I can't remember the last time I opened a native email or word processing application on desktop. I much prefer the web experience. What makes it the wrong tool? What's the point of these silly rules?

You want to build applications? Use whatever freakin tool or platform your users will adopt. Don't be constrained by pointless prescriptivism.

Re: Hotwire: HTML over the Wire

#410

Isn'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 vulnerab…

The overview video touches on how some components of the Hey app are aggressively cached, like menu popups and such - so I imagine your "offline" capability comes from the fact that anything you need to run the application offline is just cached from the last online use.
Post reply on HN