Separate Day/Night Icons

[simbleau]

I thought this would be a cool suggestion, not necessary to implement.

But I was looking for some nice day/night icons when you implemented the last commit.

It would be nice if we could use two icons, one to "turn the lights on" and one to "turn the lights off". Those wanting the current static icon can simply set both to the same icon.

[Jieiku]

I would accept a pull request for this, but I would want the icon switching done in a separate js file so that users using the static icon don't unnecessarily have more JavaScript.

(I can add another bundle option for it.)

One way you could do it, is to make a different variant of theme_button.js maybe call it theme_button_icons.js and add the functionality to that file.

[simbleau]

I've been experimenting with WASM a little hoping to learn how to tackle this one. Give me a week and I'll probably have a PR. :)

I am assuming WASM would be acceptable to you, assuming the bundle size of the WASM would be similar/lower to a JS equivalent?

[Jieiku]

yeah, wasm is great. I just dont want to load extra js or wasm for users that are using the static icon, but we should be able to add a new bundle and load it only for the users that want the icon to switch, so I don't think it should be a problem.

I experimented with different icons, and in the end I decided for my site that the static icon keeps things nice and simple.

What you are working on sounds like a great way to get better at working with WASM.

[Jieiku]

I don't want to deter you from learning WASM, but it seems for such a simple function that the javascript will actually be significantly faster/lighter. I just read over this today: https://javascript.plainenglish.io/webassembly-vs-javascript-can-wasm-beat-javascript-in-benchmark-cd7c30faaf7a?gi=a0c6c6bc5907

My take on it is that WASM is not a silver bullet and should only be used where the computation is significant enough that the wasm outperforms javascript.

[simbleau]

Ah, I knew this, however, it didn't really bother me.

Well, there's really 2 reasons it doesn't bother me.

1) WASM will be better in time. As of the present, using DOM APIs from WebAssembly is still slower than calling them directly from JavaScript. This is a temporary issue which the WebAssembly Interface Types proposal aims to resolve. If you would like to learn more, check out this excellent article (from Mozilla) which describes the proposal.

2) Good design requires compromise, and the good design is WASM everywhere in Abridge. Since JS is currently faster by the stroke of DOM API calls, it's a particularly niche situation when you either 1) have so much functional indirection it's slower than WASM (unlikely), or 2) the Javascript is extremely simple (which would be this case). In the 2nd case at least, I don't think there's a strong enough argument to keep JS on the tech stack in a sea of WASM. The performance gain would be sub-milliseconds.

[Jieiku]

If the performance difference is really sub-milliseconds then it don't matter to me at all, checking out that article you linked now.

The first article I read made it sound like javascript is 6 times faster than WASM for simple tasks, but if 6 times faster equates to less than 1ms then it don't really matter does it.

Edit: That article you linked was posted 2019 (about 2 years ago) I wonder how far along they are with this?

[simbleau]

I'll retract "would be" sub-milliseconds for probably would be. Lots of variables there.

But since this is a temporary problem, I'm going to keep prodding on, even if we don't merge it in.

Also I would lower the bar to 16ms of allowable indirection, based on 60fps, a common standard (even though I'd be shocked to witness indirection causing this much of a slowdown).

[Jieiku]

I can't wait to see what you come up with, it sounds very interesting, I am interested in most things rust.

Since its a temporary issue I think we should merge what you come up with regardless, abridge is meant to be flexible so people can either use it or not use it, but I also think wasm is where the future is headed.

[simbleau]

I forgot a decent 3rd reason: For those who disable Javascript on their browser (all 3 of them on Earth), Abridge would still work.

I won't claim good results yet. I started to look into WASM early this week from 0 experience. I am not a front-end dev. But I found exactly what I needed from this Mozilla article. I haven't ended up doing the abridge work yet...

...because I've been nerdsniped by Yew. It's been fun because I'm not a frontend dev at all (clearly), and I found the system really interesting, with props, components, and other features similar to Vue/React. Also found a CSS macro library for it called stylist-rs.

[Jieiku]

That 3rd reason is a very compelling reason, cant wait to see what you come up with even more now!

I looked at Yew quite a bit for another more dynamic project I am working on, I ended up going with Actix mostly because of maturity and I found a really good starter template that uses PostgreSQL which I also like: https://github.com/secretkeysio/jelly-actix-web-starter

[simbleau]

Isn't Actix a backend framework, like Rocket?

Yew is a frontend framework in Rust. :)

[Jieiku]

Well, the Jelly actix starter is a backend yes, but it uses tera templates to render the html (just like Zola!), so you literally just serve it up like most html, I have nginx sitting in front of Jelly Actix starter

Will need to look at Yew again, because that was a little over a year ago and I am probably confusing it with another project.

[simbleau]

Ahh. That sounds fun.

I also did some fun. I have a CI/CD pipeline which uses GitHub Actions to build the WASM website with aggressive size compression - then builds a new Docker image using the packed dist/ folder and lays an nginx server on it.

My kubernetes cluster at home detects the docker image when it updates and automatically rebuilds to the latest tag with FluxCD.

A verrrry different approach, because I focused on site reliability, but worth mentioning, since I like my solution.

[Jieiku]

ah, apparently you can use Yew with Actix or Rocket. (When you need something VERY dynamic.) Things that come to mind are things like a web music player etc.

EDIT: That is very interesting, I mostly use Proxmox out of convenience, but I have used docker occasionally. I find that proxmox LXC containers have less overhead than docker, but I know for massive projects kubernetes can be used to scale.

when you said to build the WASM website, does this mean you have an entire site using wasm?

EDIT: Nevermind, I see all the rust files on the page you linked, so this is the Yew project, can't wait to see it once it is live.

[simbleau]

Just finished the theme switch WASM piece and demo. Just a few minutes to upload...

Edit: https://github.com/simbleau/abridge-wasm I've invited you to be a collaborator so you may push things or blow up the project at will.

Right now it's just 2 buttons which change the class on the body element between 2 stylesheets. (e.g. global theme)

Eventually we can work on porting all elements, including search #41 and others.

Honestly exhausted or I'd make the demo better and not spaghetti but I found the will to pump this out before bed. I thought the clarity was decent enough as is.

[Jieiku]

Awesome, will check it out in a bit, have a good night.

[simbleau]

Progress update: Just got finished a theme switcher for my website in progress.

It now is exactly how the abridge switcher works in complete WASM:

• On page load, query local storage for your theme choice. If there is no theme choice in local storage, it performs a media query to check your browser's preference
• Changing themes will save a theme choice into local storage

I'm really happy with the results and I've learned a lot. We will start to see more experiments in abridge-wasm and probably the first pull request into abridge to introduce WASM.

[Jieiku]

Awesome! Happy 4th of July!

[Jieiku]

Closing for now (stale). Not opposed to an icon switcher so long as it is not the new default. I like the static icon as the default.