6 ms·

Ask HN: What do you think about developing a web front with Vanilla JavaScript?

7 points by Farer 2y ago

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/

deleted 2y ago
[deleted]
satvikpendem 2y ago
I think at the very least, TypeScript should be used.
- Farer 2y ago
  Of course, type safety is great, I understand that. But I want to know the detailed reason why. Why do you think it's so important?
  - solardev 2y ago
    It's a developer experience thing. Moves many bugs from runtime to coding time, letting you catch them preemptively and fix them right in the IDE without going through build cycles or hot reloads. You instantly know if something will break because of mismatched types. Probably doesn't matter much for performance. It all gets stripped away during build anyway.
    - Farer 2y ago
      I've worked with various frameworks and libraries in the past, like Prototype, jQuery, AngularJS, React, and Next.js, but I think I've ultimately come to trust Vanilla JavaScript the most. Compared to developing with Vanilla, I noticed that using these tools often results in unnecessary code in the final product. As a side note, I was never really fond of jQuery, even when it first came out, and it ended up becoming almost obsolete. Lately, I'm also not entirely happy with the direction React and Next.js are heading. It could just be because I've grown so accustomed to Vanilla JavaScript.
      - satvikpendem 2y ago
        Those frameworks are unrelated to TypeScript, as you can use TypeScript as a preprocessor for vanilla JS DOM operations.
        Farer 2y ago
        Okay. I think what I said might cause some misunderstandings. As I mentioned in another comment above, it seems to be because I don't like adding builds, compiles, issues, etc. that are not pure JavaScript. I also like TypeScript. It ensures stable development, right? There probably isn't anyone around you developing with vanilla JavaScript, is there?
        satvikpendem 2y ago
        Why would there be? Everyone I know has migrated to TypeScript.
        Farer 2y ago
        And are you using React and Next.js these days?
        satvikpendem 2y ago
        I am but more so because I like them, there is no need to use them with TypeScript.
        Farer 2y ago
        Not a single exception? :)
        satvikpendem 2y ago
        Honestly, no, I haven't heard of anyone in my circle still using JS without TypeScript.
      - 2y ago
solardev 2y ago
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.
- Farer 2y ago
  Ah, the reason you feel it's slow is because the server is located in Seoul, Korea. You're probably not in Korea, which is causing some network latency. If you try adjusting the map to a single spot and wait for a moment without moving it around, you'll notice it runs more smoothly. I also want to mention that the map size is 245,760 x 138,240, which is exactly 128 times 1920 x 1080. I’ve managed to make that enormous map, along with the data for hundreds of thousands of weeds and countless rabbits, run smoothly without issues. It even works perfectly on mobile phones. If I get the chance, I'll integrate Kafka and set up servers abroad.
  - solardev 2y ago
    Yes, some of it may be network lag (asset prefetching can help) but some of it is also just UI jank that has nothing to do with the network. I wouldn't really call it smooth compared to an optimized mapping lib like the other ones. Have you done any benchmarking by FPS, or even just noticing what happens visually when you pan (things blink in and out of existence, for example). Keep in mind that it's already more optimized than any code I could write on my own (kudos!), just not as smooth as the big solutions. If you don't want to use them, more power to ya! Just providing one opinion because you asked for it. Not necessarily trying to convince you to do it differently if you don't want to. Typically people will have made up their minds already anyway, lol.

Farer 2y ago
I totally get what you mean. I'm also someone who finds compiling or building unnecessary when running JavaScript in the browser. It feels like we end up studying and dealing with issues that aren't directly related to actual development. I really like TypeScript as well. In fact, the back-end of this project is developed with .NET 8.0, and since TypeScript gives off a similar vibe to C#, I genuinely enjoy using it. I've already made the web front-end open source: https://github.com/Farer/breathingworld_client_web https://github.com/Farer/breathingworld_client_web Even though I’m using Vanilla JavaScript for personal preference and to minimize performance issues, I’ve also been concerned about potential challenges when collaborating with others in the future. I’m currently looking for collaborators, but it hasn’t been easy. Honestly, I might be going against the trend, but that’s a possibility I’m aware of.
- wruza 2y ago
  If you wanna try ts frontend with no friction, start with Vite, a modern dev and build tool for frontend. It’s mostly zeroconf, everything just works.
  - Farer 2y ago
    Oh, I briefly looked over Vite but haven't actually used it yet. This is a good opportunity to seriously take a look at it. Is the final HTML and JavaScript code generated clean and without unnecessary bloat? As always, minimizing the resources that a first-time visitor has to download is one of my main goals as well.
    - wruza 2y ago
      Vite minimizes prod builds by default. Generates three bundles, html, js, css. Plus sourcemaps. Can’t tell if any of it can be turned off. As of bloat, it depends on your tsconfig (ts part, not vite). If you set ts up to modern standards (es20xx), it emits code basically verbatim. If you’re gonna support ancient browsers, it will have to emit some es-to-es boilerplate. See tsconfig.json reference for details. Everyone - editor/lsp, tsc, vite, eslint - look into this file. Typescript’s general idea is to just erase types, but they added some es version practicalities cause otherwise that would create a whole “pipeline” yet again for a common use case.
  - Farer 2y ago
    Oh, I see. Have you used other frameworks like React or Next.js, Svelt and so on ? If so, do you think Vite has clear advantages compared to those frameworks?
    - wruza 2y ago
      Vite is a “bundler”, a dev/build tool. You can vanilla js with it as usual. It takes your index.html and sucks in a whole dependency tree to shake it and either produce a production bundle or run a dev server. Being aware of ts, vue, react, sass, etc out of box is its bonus points. Vite vs React vs Next is crates vs oranges vs boxed oranges. I know react but never touch it. React, vue, svelte are “state management”. I’m using mithril.js with POJOs for my frontends. Vanilla everything gets messy in interactive apps, and I come up with a poor man’s mithril usually, then rewrite for it.
      - Farer 2y ago
        Oh, so you're developing a bit differently from the current trends. Interesting. As you mentioned, when developing with vanilla JavaScript, it can become difficult to maintain as more features are added or the service grows. However, if you plan carefully, it’s not necessarily a big issue, though many might find it challenging. Do you have any ongoing projects by any chance? Perhaps a project where you're utilizing Vite and Mithril effectively?
        wruza 2y ago
        I understand trends, but don’t understand why I’d need them. It’s extra work for nothing. But updating dynamic ui requires thought that aligns with m() ideas for me. That’s it, my whole reasoning. Made numerous projects with m(), inhouse dashboards/forms, crypto/stock trading tools, RC buggy debug interface. Currently a set of crypto-related db views again. Not sure if I want to share the code though. Just read mithril guide if interested, it’s very short. I don’t do anything funny with it. If it clicks, it clicks. If not, ignore it.
        2y ago

Farer 2y ago
Okay, thanks. I have one question. What exactly do you mean by something disappearing and reappearing when panning? Could you explain the phenomenon in a bit more detail? Actually, when zooming in or out quickly, there’s a momentary effect where what was previously rendered lingers for a bit. I don't see this as a major issue, considering it aligns with the concept of eventual consistency. Also, what exactly is the large-scale solution you mentioned? Regarding the movement of the rabbits’ coordinates, it might not appear smooth when zoomed in significantly. This isn't necessarily a performance issue but rather something related to how the animals' coordinates are processed. I plan to improve that part in the future. Anyway, thanks for your interest. I'll definitely consider your feedback!
- solardev 2y ago
  > What exactly do you mean by something disappearing and reappearing when panning? Could you explain the phenomenon in a bit more detail? When you pan (click and drag, or touch and drag on a phone), all the bushes and the background disappear for what feels like a second or two, even if they're the same bushes as before. No network connections are happening during that pan, it's just a redraw that causes them to blip in and out: https://share.cleanshot.com/KvwXCVl7ZpLYk8KzFBN1 https://share.cleanshot.com/KvwXCVl7ZpLYk8KzFBN1 On Firefox the panning (before mouseup) is itself much laggier than Chrome. (Firefox generally has slower graphics, in my experience). It also suffers from the disappearing graphics on mouseup issue. Same thing happens if I zoom in and out, one mousewheel notch at a time - everything momentarily disappears before rerendering. > Also, what exactly is the large-scale solution you mentioned? By "big", I just meant literally the larger libraries I mentioned earlier (Leaflet, OpenLayers, OpenSeadragon, Konva, Pixi.js, etc.). They're bigger in both in popularity/mindshare, but also in filesize and complexity, which is what you're trying to avoid. However, they do have optimizations for the graphics rendering pipeline that maybe you can borrow from, if you look at their source code. Some examples: * https://openlayers.org/en/latest/examples/icon-sprite-webgl.html https://openlayers.org/en/latest/examples/icon-sprite-webgl.... (this one in particular is super smooth for me compared to your app's current version, but it uses WebGL) * https://openlayers.org/en/latest/examples/synthetic-points.html https://openlayers.org/en/latest/examples/synthetic-points.h... (demo without WebGL, much laggier) * https://konvajs.org/docs/sandbox/20000_Nodes.html https://konvajs.org/docs/sandbox/20000_Nodes.html * https://www.goodboydigital.com/pixijs/bunnymark/ https://www.goodboydigital.com/pixijs/bunnymark/ * http://fabricjs.com//group-dragging http://fabricjs.com//group-dragging * Benchmarks: https://github.com/slaylines/canvas-engines-comparison?tab=readme-ov-file https://github.com/slaylines/canvas-engines-comparison?tab=r... (current build seems broken)
  - Farer 2y ago
    And the map UX isn’t complete yet. I also plan to finish a smooth map UX like Google Maps or the ones you mentioned. I’d appreciate it if you could keep an eye on it a bit longer.
  - Farer 2y ago
    Oh, I get it now! Currently, when dragging or zooming in and out, the ground, weeds, and rabbits are being redrawn. Of course, for the weeds, the browser is using a cache of about a minute, but due to network latency, this part might be even more noticeable to you. I personally really like Firefox as a browser, but as you mentioned, I'm quite disappointed to see that its rendering performance is relatively poor. I'm also a bit worried about whether it will continue to receive good updates. (A long time ago, I even bought a smartphone that came with Firefox OS. lol) I'll definitely need to take a proper look at the solutions you mentioned this time. I also remember Konva being very useful in the past. Thank you for the detailed and kind response.
  - Farer 2y ago
    Since this project is just starting to implement canvas, there might not be any noticeable visual performance improvements yet. I imagine I’ll probably start using WebGL as more animals are added.

Farer 2y ago

As I mentioned in my previous reply, I've been using nearly every major JavaScript library and framework for almost 20 years. After all that, I ultimately came to the conclusion that Vanilla JavaScript is the best. Especially when it comes to the build processes involved in updating modern web front-end source code, I've found the experience quite unsatisfactory. On the server side, you can compensate with better server specifications and resources, but with web front-end development, it's essential to ensure compatibility across various browsers while using minimal resources. This is how you can provide the best possible experience to the largest number of people. Of course, if you want to avoid relying on other solutions, it's true that you need to be very familiar and experienced with Vanilla JavaScript.

solardev 2y ago
Nobody is forcing you to use a library (much less a full framework) if you don't want to. Yes, they're often a pain, and often result in a shitty DX. It's more that the big name libs for this use case have a lot of optimizations, both server-side (like raster and vector tiling, CDNs) and client-side (asset and viewport virtualizations, prefetches, offscreen canvas rendering, etc.) learned over decades of doing web mapping & graphics that don't seem to be implemented in your app yet. They're all open source, so you can look at their techniques if you want. Especially their performance stress test examples. I don't mean to make this a philosophical debate about libs vs writing your own code. You asked for opinions about the performance of your app, and I'm just providing one person's feedback. It's better than anything I could've written on my own, but not as fast as the major libs.
- Farer 2y ago
  Got it. I just want to clarify that I'm not someone who thinks all my ideas are always right, so I hope there’s no misunderstanding. Also, could you provide links to the libraries you mentioned? Of course, I’m always eager to study more about areas I’m not familiar with. This project is primarily focused on performance, after all, so I’d appreciate it if you could share them. I also agree that optimizing the canvas for GPU usage is something that definitely requires more research. Since I plan to add more plants and animals, it will be crucial moving forward. Thanks again for your valuable input!
  - solardev 2y ago
    Some examples in my other reply: https://news.ycombinator.com/item?id=41915571 https://news.ycombinator.com/item?id=41915571 In particular, if you want to go lower-level (i.e. more control over graphics, rather than something optimized for web mapping in particular), I'd look at Pixi.js Good luck!
    - Farer 2y ago
      Thanks for your kindness! I will see it too.

Farer 2y ago

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 https://github.com/Farer/breathingworld_client_web

solardev 2y ago
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.
- Farer 2y ago
  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?
  - solardev 2y ago
    > 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-faster https://felt.com/blog/from-svg-to-canvas-part-1-making-felt-.... Figma too, but it's less a direct comparison to your app.
    - Farer 2y ago
      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?
      - solardev 2y ago
        > 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?
        Farer 2y ago
        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!