Arc Forumnew | comments | leaders | submitlogin
Show Arc: /l/place, a clone of reddit's /r/place written in Arc. Draw something! (laarc.io)
4 points by shawn 68 days ago | 19 comments


3 points by i4cu 67 days ago | link

It's cool, but it's doing a new page request per interaction and the page load takes at least a second. It also has a looong painting operation. :(

This is where js would be handy - right? Personally I would just update the dom element and send a http post in the background.

I get that it's just a toy, but still it shows that languages* should have a good client side story too. Maybe some Lumen integration?

* that are for the web.

edit: reminds me of the million dollar homepage http://www.milliondollarhomepage.com/

-----

3 points by krapp 67 days ago | link

>This is where js would be handy - right? Personally I would just update the dom element and send a http post in the background.

If it's to be done in JS, might as well implement a drawing tool in an actual canvas element.

I've seen tutorials that are reasonably simple. The complicated part would be actually saving it. It is possible to export a canvas as a png and upload it with an AJAX request but I don't know how cross-browser compatible that is.

-----

2 points by shawn 67 days ago | link

We tried. It was almost a disaster.

We started out by making an EventSource endpoint and using JS EventSource object to get updates. Seemed to work great.

Pushed it live.

To everyone on the site. Not just to the people on /l/place. Oops. Mistake #1.

Mistake #2: I was aware that Arc kills threads that take longer than 30 seconds, but I was unaware that EventSource automatically tries to reconnect. Welcome to the DoS party.

With no way to tell the clients to stop. Mistake #3.

It was only live for about 10 minutes, but it took around two hours before the last few clients finally refreshed their browser and stopped DoSing the endpoint. The server absorbed the extra traffic like a champ, but the server logs were ridiculous for about an hour. Lots of "client took too long" error messages spit out by Arc every second.

Sooo yeah, submitting changes via JS is easy. Getting updates is the hard part.

Could poll. But then that's still hammering the server. Moreso than it already is.

It's probably a feature that it's painful to use. Only the determined will use it for art.

That said, if anyone has ideas for how to tweak arc for performance for this scenario – and remember to calculate how much memory is used by how many simultaneous sockets are open – I'd be willing to try again.

-----

3 points by i4cu 67 days ago | link

Reads like a really good horror story :)

> I was aware that Arc kills threads that take longer than 30 seconds...

> Sooo yeah, submitting changes via JS is easy. Getting updates is the hard part.

That's why I suggested a post request...

Just deliver the page and create an api end point, on the server, that gives you the last x changes from the change log.

With that ajax request, you could return these net updates for the client and use client side js to apply them to the dom. You could even create a trivial js debounce[1] algo to throttle requests if you wanted to go even further.

1. 'debounce' for those who don't know -> https://davidwalsh.name/javascript-debounce-function Only I'm suggesting it as a way to throttle ajax reqs.

-----

3 points by shawn 65 days ago | link

Yeah, it was worth the effort to make the drawing code client side. Someone showed up and made a software rasterizer.

Timelapse: https://www.youtube.com/watch?v=G0sG08jKCTI

-----

2 points by krapp 63 days ago | link

why not go all the way and render client-side in a canvas as well?

As it is, the more "pixels" you have, the slower the page loads. You could probably have just a single canvas and a single event handler.

You could preserve functionality for non-js users by using an imagemap (assuming browsers still even support those) or sticking the existing code in noscript tags.

-----

2 points by krapp 62 days ago | link

OK... I don't know where I got "single event handler from," that obviously wouldn't be true, but it would still be simpler than having each pixel be a separate HTML form....

-----

1 point by shawn 62 days ago | link

Wanna hop into discord and we can chat about the design? https://discord.gg/qaqkc9z

The repo's open, and I could help get you set up with it if you wanted to work on some of this. https://github.com/laarc/laarc

It should be a matter of:

  git clone https://github.com/laarc/laarc
  cd laarc
  make
  rlwrap bin/arc
  ((load "news.arc"))
and then http://localhost:8080/place

-----

2 points by krapp 62 days ago | link

Let me actually see if I can come up with a POC first, at least for the canvas and javascript. Realistically, since it's just GET requests that don't need authentication, I shouldn't even need laarc running, I can just send the same requests by AJAX.

-----

2 points by shawn 62 days ago | link

https://www.laarc.io/place.json is the API, by the way! I should probably mention that somewhere.

-----

2 points by shawn 66 days ago | link

Kay, it's all client side now. Have fun!

-----

3 points by i4cu 66 days ago | link

Much better.

I will say; I did a page reload and noticed the color pick was still in place and had to go hunt for the x. I expected it to reset, but I'm not sure if you see that as a bug or a feature :)

also, it looks like the client side is pure js... Is Lumen not up to that task? just curious if you tried that as it might be nice if, someday, we could get to the point where this kind of stuff could be done in arc.

-----

3 points by shawn 65 days ago | link

Thanks for mentioning that. It's a bug.

The trick to clear the x is to scroll up and click on the color palette.

Here's a timelapse for the curious. https://www.youtube.com/watch?v=G0sG08jKCTI

-----

3 points by krapp 67 days ago | link

I like it, but to be honest, I find tags more interesting than the drawing tool.

I'm also stealing your color scheme once we get themes working here... yours and every other clone I can find ;)

-----

2 points by shawn 67 days ago | link

Stick around! We like submissions :)

https://www.laarc.io/l/dev|programming for general programming stuff

lisp: https://www.laarc.io/l/lisp

essays+classics: https://www.laarc.io/l/essays|classics

videos: https://www.laarc.io/l/videos

And you can make your own tags: https://www.laarc.io/submitlink?l=whatever%20foo%20bar

(That would post a link to /l/whatever, /l/foo, and /l/bar.)

-----

3 points by krapp 67 days ago | link

It looks like it's possible to draw without being logged in.

You might want to fix that, otherwise the whole thing looks like a DDOS attack waiting to happen.

-----

2 points by shawn 67 days ago | link

'Tis a feature, not a bug.

Bonus: the whole thing runs on a $5/mo FreeBSD droplet. Arc's performance is just that good.

The graphs have been incredible: https://imgur.com/a/ripfcK7

I guess people really like toys written in arc....

You're right about the DDOS. Someone from the Czech Republic wrote a script to wipe the map. It briefly froze up the server.

I solved that by cloning the endpoint, disabling the old one, optimizing the new one, then rolling back the board by 1 hour. The scripter stopped.

If stuff like that keeps happening, I imagine we can fight it via cloudflare firewall rules.

-----

2 points by shawn 67 days ago | link

The code is about 100 lines: https://github.com/laarc/laarc/blob/master/news.arc#L3506-L3...

Every pixel is a form with a button.

-----

2 points by shawn 67 days ago | link

Permalink for posterity https://github.com/laarc/laarc/blob/4affa5de9fa28d312c3e57d0...

-----