46 comments

[ 3.2 ms ] story [ 100 ms ] thread
TLDR: It's a basic chat app. It's using a streaming http connection and css "::before" to reverse the order of new output, so it doesn't need javascript. Interesting hack, but...
But what?
It breaks when you press `esc`. Either that, or the DOM just keeps growing and hogging memory until the tab eventually becomes unresponsive or crashes
Thanks, but isn't this the same if you use a virtual DOM? Is Mithril not prone to this problem if you keep adding stuffs to the list?
With javascript you can keep an EventSource connection open (which is immune to the `esc` thing), and you can prune the DOM and let the browser GC.
Thanks for the explanation. I'm too green to understand this, but I'll try to learn more about it later.
Presumably you'll eventually write something rather than lurking for hours and then it'll refresh.
In extremis a <meta refresh> could be used.
But then if you refresh every ten minutes or so, and I just happen to be finally responding after that long, I'm going to lose what I'm typing.
Not necessarily: browsers are pretty good at keeping form elements state across refreshes nowadays, especially Firefox. Cursor position perhaps, but not text.
Perhaps, but certainly there will be frustration there. Especially WRT cursor position changing.
I mean, sure, it works just fine if people refrain from doing certain arbitrary things (such as the scripted spamming that's happening as I write this), but that's why the grandparent comment said it was a hack and not a trick that one might want to attempt in production.
The spam had nothing to do with not using Javascript. I could easily have added a CAPTCHA or required accounts.
My Surface tablet got warmer and warmer on my lap.
The CSS to reverse the order is:

    main {
        display: flex;
        flex-direction: column-reverse;
    }
The many ::before <style>s are used to update the connection count.

If you like these kinds of tricks, there's also an "order" CSS property, which lets you give elements any arbitrary order you like (by giving each element a numeric index). This can be useful for implementing sorting functionality, for example.

I guess this works by keeping the connexion alive and streaming packets of data, taking advantage of the browsers capacity to render HTML before the whole source is actually loaded.

OP?

Correct. It's a small Golang server that keeps the connection alive with chunked transfer encoding. From the browser's perspective it's like a really slowly loading page.

The connection count is updated by sending some inline CSS ::before content changes.

Thanks for the demonstration. I didn't know this chunked encoding technique before.
This is a really cool hack. Is the source code available somewhere? I understand how the updates are showing up in my browser (using CSS ::before and never closing the connection), but can't figure out how the post works without refreshing the page. Can't view source because the page never actually finishes returning. I'm probably forgetting something basic.
You're forgetting about F12 :)
(comment deleted)
The POST requests do refresh the page for the poster. But not for the viewers. For everyone else it just streams the HTML to them using chunked encoding.

It's written in Golang and hosted on a free Heroku instance. I'll probably upload the code somewhere after a bit.

Oh wow, I couldn't really notice the page refreshing at all... Nice job.
Thanks. There's a subtle trick where new comments (from streamed updates) have a CSS animation but comments from the page reload don't. It seems to make it feel more seamless.
What's with the shitty people? "Europeans are useless", "fuck white people", "fuck black people" etc. Ludicrous.
That's what happens when everyone is anonymous and the text scrolls fast, you can't even have a proper conversation so those types of people leave and you are left with a trollbox.
Keep in mind these are the same people whose comments you're reading on HN and the same people upvoting/downvoting whether or not your contributions are seen. Pure anonymity sucks.

Also see John Gabriel's Greater Internet Fuckwad theory: https://www.penny-arcade.com/comic/2004/03/19

This is partially alleviated by the fact that you can't downvote until you reach a certain karma threshold.
> Keep in mind these are the same people whose comments you're reading on HN and the same people upvoting/downvoting whether or not your contributions are seen.

Yeah I'm just starting to realise this. Big disappointment.

If you liked that, you might also enjoy this little hack. How about real-time updates without JavaScript or CSS tricks?

http://zesty.ca/chat

(1999)

At the bottom it says that it uses JS to not require refreshing after each message. This is not necessary as the form can submit to a frame using the target attribute without refreshing the parent frame.
(comment deleted)
This is a funny trick, and known for ages, except the CSS-based re-ordering of the incoming info.

It's probably not practical for a chat app (DOM just grows infinitely), but it's a great way to show progress of a longish-running process with a bare minimum of means.

Compared to using a socket server, how many connections can this server maintain?
Presumably the exact same number. A TCP connection is a TCP connection.
If anyone wants to delegate streaming HTML connections like this, it should be possible with Fanout (https://fanout.io) which supports arbitrary content.
It's being flooded with spam now. This is why we can't have nice things.

Anyway, it was just a proof of concept. The spam could be blocking using some captcha or registration if necessary.

Also no filtering, you can just chuck raw HTML in there
That's not true. I allowed b, u, i for a while but people kept not closing them so even those are disabled.
And someone wrote a script to overload it. ~Nice Try~ :D
Overloading it was failing. But the spam was too much (it was posting so fast you couldn't read anything). I meant for this to just be a fun example of noscript updates so I'm probably not going to add captcha/IP filtering or anything.

People...

interesting that neither chrome or firefox network dev tools can/will show a response for the 'GET' request