Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TodoMVC App Written in Vanilla JavaScript

github.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: TodoMVC App Written in Vanilla JavaScript

#91

Post by mmcnl »

How many people who are critical of the current state of JS actually use it on a daily basis? Modern frameworks like React and Vue don't exist to fill in the gap left by native JS, they exist so that you write your application in a declarative way where the view is rendered as a function of state. This relieves the developer of keeping track of DOM state, as you only declare the render function once, and after that you only need to manage state.

If anything, modern frameworks tend to build as much upon the native functionality that is available. This reduces bundle sizes and increases performance. It's an abstraction on top of the browser capabilities, not a clone.

Now, onto the code itself. The author claims it is "pretty simple" to build "fairly complex things". He backs up the claim by stating it took only 60 minutes to write this app.

First, I would be careful to claim things are easy or difficult. This is very subjective, and phrased in the wrong way it can also come across as arrogant.

Second, the app is not simple. Looking at the code the author created his own DOM abstraction. The current abstraction is only proven to work for a simple to do app.

Third, a to do app is not a "complex thing". Not even remotely.

It's a nice exercise, but the conclusion drawn by the author aren't valid.

Re: TodoMVC App Written in Vanilla JavaScript

#92

Post by skybrian »

It would be a different demo, but this could be made fairly modern with some lightweight tooling and dependencies:

- Use esbuild to bundle the app. - Now you can change the file extension and switch to Typescript. (Esbuild doesn't check the types, but VS Code will.) - Then change the file extension to tsx and use Preact.

I'm writing a little app this way and it seems quite nice. I don't think I'm missing anything?

Re: TodoMVC App Written in Vanilla JavaScript

#93

Post by yuzuquat »

Hey! This is really awesome. I'm building my own SPA in vanilla js, and I'm definitely stealing some ideas here. I think a lot of people here see the resurgence of vanilla js as a repudiation of their favorite framework. There's a definitely a time and a place for both, and it's never bad to take a break and revisit the basics

Re: TodoMVC App Written in Vanilla JavaScript

#94

Post by 1marc »

yuzuquat wrote: post #93

Hey! This is really awesome. I'm building my own SPA in vanilla js, and I'm definitely stealing some ideas here. I think a lot of people here see the resurgence of vanilla js as a repudiation of their favorite framework. There's a definitely a time and a place for both, and it's never bad to take a break and revisit the basics

Thank you! Agreed!

Re: TodoMVC App Written in Vanilla JavaScript

#95

Post by deergomoo »

recursive wrote: post #45
Philip-J-Fry wrote: post #9

The thing I enjoy about frameworks like React is the declarative nature of the UIs. I'd love to not be able to use them and to create complex UIs in pure JavaScript but it always ends up being painful where you spend more time optimising the rendering than doing any work. In simple apps I will write UI in a functional matter in pure JavaScript, regardless of the performance implications. But bigger DOM means worse pe…

Cases where "UI should be a function of state" seem like a small sliver of all use cases. Probably not worth the complexity for implementing directly in the browser. And there are plenty of conditions that just prohibit the pattern entirely as far as I can tell. Things where referential stability matters, like you have a contentEditable or allow arbitrary edits on a canvas.

Personally I would argue that UI should always be a function of state. When it isn’t, you open yourself up to all sorts of inconsistencies and difficult edge cases. Of course, it’s not always that easy; having two sources for said UI (the HTML document itself and the JavaScript within it) certainly complicates matters.

Re: TodoMVC App Written in Vanilla JavaScript

#96

Post by 1marc »

skybrian wrote: post #92

It would be a different demo, but this could be made fairly modern with some lightweight tooling and dependencies: - Use esbuild to bundle the app. - Now you can change the file extension and switch to Typescript. (Esbuild doesn't check the types, but VS Code will.) - Then change the file extension to tsx and use Preact. I'm writing a little app this way and it seems quite nice. I don't think I'm missing anything?

Agreed, esbuild is nice. And adding TypeScript at some type of scale probably makes sense. Not sure where that line is, but in this simple example I’m trying to avoid all external tools.

Re: TodoMVC App Written in Vanilla JavaScript

#97

Post by moffkalast »

wildrhythms wrote: post #78
moffkalast wrote: post #69

Earlier quoted context omitted.

> How would you reuse a "component"? Save the element template as a string and set innerhtml of a div as that? > compromises today that don’t make you re-invent the wheel Yeah but there's also no need to include jQuery and bog down your site with piles of code you won't ever call just because you don't know how to use the native api like a normal person. React/Angular/whatever are just the latest fad of that mindset,…

What happens when you need to update some deeply nested child element without re-rendering the whole tree? Suddenly you need some system of labeling the children, how to find them in the dom, how to update them, how to keep them in sync with the state... a vanilla JS solution becomes extremely unwieldy as soon as you step out of the "global pointers to elements" phase (what the project in the OP is). Lit-html is an e…

I mean speaking for myself, I mostly make robotics web apps which isn't the most typical of web applications but the times this sort of thing is needed are few and far between.

So yes, this pattern is helpful for solving that sort of thing when it occurs (and if the use case is even substantial enough to warrant it) and Lit looks like it would fit that role reasonably well, but basing the entire site on this principle as a full on framework seems a bit ludicrous.

What html actually lacks is the option to include external html part files, but there are lots of ways to do that serverside that don't involve the stupid idea of putting html into strings in js files for literally everything.

Re: TodoMVC App Written in Vanilla JavaScript

#98

Post by klabb3 »

mmcnl wrote: post #91

How many people who are critical of the current state of JS actually use it on a daily basis? Modern frameworks like React and Vue don't exist to fill in the gap left by native JS, they exist so that you write your application in a declarative way where the view is rendered as a function of state. This relieves the developer of keeping track of DOM state, as you only declare the render function once, and after that y…

> React and Vue [...] exist so that you write your application in a declarative way where the view is rendered as a function of state

Exactly. To elaborate, here's the big, big caveat in a miniature form:

https://github.com/1Marc/todomvc-vanillajs-2022/blob/854dd40...

Note that this clears and recreates the DOM on every action (eg mark complete), and DOM ops are the most expensive ones. This is a sound strategy for vanilla JS, because the alternative is mutating the DOM and keeping it in sync which is error prone to put it mildly.

I use frameworks very sparingly, and am always cautious with deps. But a reactive UI/diff engine is non-negotiable for me.

Re: TodoMVC App Written in Vanilla JavaScript

#100

Post by qudat »

Now add 500 more features and 10 engineers and see if it scales. Hint: it doesn’t. Sure you can make it work, but as someone who regularly makes FE decisions for a team, I wouldn’t want to impose vanilla on them.

What I will say is it’s tough. I don’t like the idea of react at this point. I like building products that don’t need something heavy like react/redux.

I recently launched https://lists.sh to scratch that no js itch. It was a ton of fun and I want to chase that feeling.

But building a web app is what businesses want. And while you could make vanilla js work, you’d be reinventing a lot of tooling to get you there.

Post reply on HN