←back to thread

7 points Farer | 1 comments | | HN request time: 0s | source

What do you think about developing a web front-end with Vanilla JavaScript to minimize performance issues?

I believe I have reached a certain level of success. The canvas seems to have excellent performance. Could you take a look at the ongoing test and provide feedback?

https://alpha.breathingworld.com/

Show context
solardev ◴[] No.41913611[source]
IMO I think this is pretty laggy once you zoom in, at least on my phone (Pixel 7 running Chrome).

Switching zoom levels takes a long time to load the assets. The bunny has some temporary displacement relative to the background. Panning results in visible lag.

I don't think vanilla is a magic performance pill. Everything compiles down to vanilla, after all, and in this case this app's performance seems quite a bit slower to me than Leaflet, OpenLayers, OpenSeadragon, Konva, Pixi.js, etc. I haven't looked at your code, but maybe it could benefit from tile-based rendering and asset virtualization?

I also think if this is the extent of your desired usage (rendering graphics on a zooming panning canvas) you're reinventing a wheel that's already been invented, abandoned, reinvented, improved, forked, improved, rewritten a thousand times. Why do you want to? Just for fun? To make an even better one? To make a custom game or mapping engine? Those are all fine, it's just a lot of work with uncertain payoff vs using a ready made library (not necessarily framework).

Just my opinion. I'm a lazy dev though.

replies(3): >>41913830 #>>41913916 #>>41913956 #
Farer ◴[] No.41913956[source]
Oh, and the source code is already made public, so if it's okay with you, could you take a look at it? If you could point out any parts I might have missed, it would be a huge help.

https://github.com/Farer/breathingworld_client_web

replies(1): >>41914920 #
solardev ◴[] No.41914920[source]
I'm not qualified, you already did a better job than I could've :) I'm a die-hard "don't reinvent the wheel" kinda guy who will use other people's optimized solutions instead of writing my own, whenever possible.
replies(1): >>41915085 #
Farer ◴[] No.41915085[source]
Yeah, I know this saying well: "Don't reinvent the wheel." I completely agree with it, too. I mean, I’m not building a browser engine from scratch here, right? lol

But when it comes to web front-end development, I often feel that frameworks and libraries shift too much focus away from actual development, making you worry about things that aren’t really necessary. After all, JavaScript in browsers isn’t compiled like other languages. The main thing that reduces loading times is using cache, right?

replies(1): >>41915720 #
solardev ◴[] No.41915720[source]
> After all, JavaScript in browsers isn’t compiled like other languages. The main thing that reduces loading times is using cache, right?

I think a differentiation between a full framework (like Next.js) and a lib (like a Canvas rendering lib) is helpful here. There's a lot more that goes into modern web graphics rendering than just caching, including optimizations within JS itself, its interactions with Canvas and the DOM, WebGL, WebGPU/WASM for expensive calculations, virtualizations, tiling, transformations/filters, etc.

I'm not a graphics programmer so I can't get into much detail here, but I think of it as the difference between making a game in an existing engine (Godot, Unity, Unreal) vs trying to make your own engine and rendering pipelines. It all compiles down to machine code, but their optimizations can be several orders of magnitude better than what a solo dev can realistically write in their own time.

With Canvas rendering, there's been a lot of techniques that companies have worked on over the years. Take a look at Felt, for example, to see a full web app that makes extensive use of render optimizations. They have a nice writeup about it: https://felt.com/blog/from-svg-to-canvas-part-1-making-felt-.... Figma too, but it's less a direct comparison to your app.

replies(1): >>41915832 #
Farer ◴[] No.41915832{3}[source]
Yes, that's exactly what I wanted to say! In the end, the browser just reads and processes the given HTML, CSS, and JavaScript. And now it feels like the discussion has shifted from whether to use vanilla JavaScript to the graphic rendering issues in my current project. Still, as we continue this conversation, I feel like I'm being reminded of new challenges to tackle. I like it!

P.S. Are you a web front-end specialist?

replies(1): >>41916102 #
solardev ◴[] No.41916102{4}[source]
> I feel like I'm being reminded of new challenges to tackle. I like it!

Lol, there's no shortage of that in the web world! Every two years or so, right when I feel like I kinda sorta mastered something, it's obsolete and replaced by the new shiny...

> Are you a web front-end specialist

Yes, sort of? I'm a frontend dev with some past full stack experience, but it's all mostly self-taught and I don't have a real comp sci or math background, which means a real weakness when it comes to data structures and algorithms. Especially for graphics, it's a hindrance.

I just happened to grow up with the Web, having learned HTML before CSS and JS were invented, and kinda sorta kept up with it over the decades. Overall I'm a pretty mediocre dev though, especially when it comes to algorithmic optimizations, so you'll have to find someone else for help with that part :) Maybe reach out to some of the lib authors after reviewing their code?

replies(1): >>41920731 #
1. Farer ◴[] No.41920731{5}[source]
That's right. Web frontend has always been constantly changing. And that's what makes it even more fun. Because of that, I try not to focus too much on new technologies. Of course, new challenges are always meaningful, and over time, if they become well-refined, they might settle in as standards. I'm really glad to have had such a great conversation through this opportunity!