←back to thread

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

7 points Farer | 9 comments | 22 Oct 24 02:50 UTC | HN request time: 0s | source | bottom

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
satvikpendem ◴[22 Oct 24 10:39 UTC] No.41912981[source]▶
I think at the very least, TypeScript should be used.
replies(1): >>41913571 #
Farer ◴[22 Oct 24 12:30 UTC] No.41913571[source]▶
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?
replies(1): >>41913644 #
solardev ◴[22 Oct 24 12:41 UTC] No.41913644[source]▶
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.

replies(1): >>41913858 #
Farer ◴[22 Oct 24 13:09 UTC] No.41913858[source]▶
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.

replies(2): >>41914832 #>>41914852 #
solardev ◴[22 Oct 24 14:47 UTC] No.41914852[source]▶
You're kinda preaching to the choir here on HN, where many people feel the same way (not me personally, but generally speaking).

That's fine, you can still use Typescript with vanilla JS and not use any frameworks. Typescript shouldn't result in unnecessary code in production. It's just developer hinting during dev, but it gets removed during the build.

If you don't want to use a build tool at all, you can also use JSDoc formatting to provide some basic type and parameter information. Your IDE can still use that to provide hints.

It's totally up to you. If it's a solo dev codebase that only you ever see and you don't want to type it, then don't :) If you do end up wanting to share the code though, Typescript makes it a lot easier for other devs to use because they can instantly see when something is wired up wrong during development.

replies(1): >>41915133 #
1. Farer ◴[22 Oct 24 15:17 UTC] No.41915133[source]▶
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

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.

replies(1): >>41921023 #
2. wruza ◴[23 Oct 24 02:08 UTC] No.41921023[source]▶
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.
replies(2): >>41921094 #>>41921323 #
3. Farer ◴[23 Oct 24 02:17 UTC] No.41921094[source]▶
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.

replies(1): >>41921265 #
4. wruza ◴[23 Oct 24 02:46 UTC] No.41921265{3}[source]▶
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.

5. Farer ◴[23 Oct 24 02:58 UTC] No.41921323[source]▶
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?
replies(1): >>41921822 #
6. wruza ◴[23 Oct 24 04:26 UTC] No.41921822{3}[source]▶
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.

replies(1): >>41921991 #
7. Farer ◴[23 Oct 24 05:06 UTC] No.41921991{4}[source]▶
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?
replies(1): >>41923848 #
8. wruza ◴[23 Oct 24 11:23 UTC] No.41923848{5}[source]▶
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.

replies(1): >>41924658 #
9. Farer ◴[23 Oct 24 13:02 UTC] No.41924658{6}[source]▶
It’s quite similar to the reason why I insist on developing with vanilla JavaScript. It’s hard to shake off the feeling that many libraries or frameworks stray away from the essence, and that’s one of the reasons. Since these are things I’ve felt through actual experience in the field, I’d like to take a look at it as well. Thanks for the good information!