TodoMVC App Written in Vanilla JavaScript • Hacker News Board

Re: TodoMVC App Written in Vanilla JavaScript

#11

Post by mch82 » Sat, May 07, 2022, 1:26 PM UTC

moreira wrote: post #6

Trufa wrote: post #3

I’m sorry but this is not a fairly complex app. When things do get more complex (and not even that much) is when you start hitting problems. How would you reuse a “component”? Among many other things. I honestly don’t know if that’s the point of the author but I would agree that many framework are too heavy, but honestly there so many good compromises today that don’t make you re-invent the wheel and fix bugs that ha…

It's a good way for people to revisit the current status quo and avoiding cargo cult. Frameworks are useful, but there's definitely an element of cargo cutting going on in the JS ecosystem whereby no matter what the requirements, you just reach for React/Vue. We're getting to a point where almost nothing that uses JS gets built without a frontend framework (and all its weight) anymore. One thing that's easy to notice…

Building on your comment, frameworks have described themselves as “polyfills”. Polyfills used to be libraries that added modern browser features to old browsers. Then, Angular and React began using polyfills to add future features to modern browsers. The intent was always communicated as “some day we won’t need this because it’s built in to HTML5 and when that happens your initial payload will be smaller”. Typescript has had similar effect on JavaScript language features and syntax.

This rewrite of the Vanilla JS TodoMVC is a great illustration of how far things have come.

Re: TodoMVC App Written in Vanilla JavaScript

#12

Post by blowski » Sat, May 07, 2022, 1:26 PM UTC

krembanan wrote: post #5

Yeah, that's exactly what I would imagine vanilla js code look like, and I'm glad we moved on to frameworks. Just this small app seems not so fun to maintain

Yep, it’s a really nice demo for how to use JavaScript. But it’s not a valid criticism of Vue, React, Svelte because it’s solving a very simple problem. The reason for those frameworks becomes clear when you have multiple people maintaining it and adding features.

Re: TodoMVC App Written in Vanilla JavaScript

#13

Post by wackget » Sat, May 07, 2022, 1:26 PM UTC

Why is there HTML inside the JavaScript? Doesn't that defy the entire point of the MVC pattern?

Re: TodoMVC App Written in Vanilla JavaScript

#14

Post by mrspeaker » Sat, May 07, 2022, 1:27 PM UTC

I like the "const TodoStore = class extends EventTarget" idea to trigger rendering... neat trick!

Re: TodoMVC App Written in Vanilla JavaScript

#15

Post by ravenstine » Sat, May 07, 2022, 1:32 PM UTC

Looks well made, code is pretty good, but why the archaic form of JavaScript other than the import statements? There's a lot of well supported syntactic sugar that would make it much easier on the eye. I also wouldn't bother with the IIFE.

Re: TodoMVC App Written in Vanilla JavaScript

#16

Post by mch82 » Sat, May 07, 2022, 1:36 PM UTC

listless wrote: post #7

The code here is clean, well written and honestly not that much more verbose than many of the framework ones. I also found it simple to understand. Would you need a “framework” when an app gets beyond TODO? I think you would need to start refactoring your code to be more framwork-like. But this is something we don’t do, and I would say would even be considered “anti-pattern”.

My bet is that as soon as someone popularizes a way to manage state across a set of web components the pendulum will swing back to the “Vanilla JS” approach. It’s so nice to work on web apps without having to install NodeJS, builders, cli tools, and so on. And it encourages software engineers to learn the web platform APIs instead of learning frameworks.

HTML and CSS are actually quite nice to work with, given modern browser developer tools. Much simpler to work with when they are literal files.

It wouldn’t surprise me if people continue to compile other languages to JavaScript or WASM though. It seems reasonable a Java developer might like to work in Java or a Ruby developer in Ruby instead of writing JavaScript. But I don’t understand how people feel confident writing web applications if they don’t take the time to understand CSS, HTML, or the browser APIs.

Re: TodoMVC App Written in Vanilla JavaScript

#17

Post by pjmlp » Sat, May 07, 2022, 1:36 PM UTC

wackget wrote: post #13

Why is there HTML inside the JavaScript? Doesn't that defy the entire point of the MVC pattern?

React people think it doesn't, and apparently that is what everyone should be using...

Re: TodoMVC App Written in Vanilla JavaScript

#18

Post by mattgreenrocks » Sat, May 07, 2022, 1:40 PM UTC

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…

Echoes of Alan Kay's recent comment on how software devs are way too concerned with the how the computer works to the detriment of what the software is supposed to do.

Re: TodoMVC App Written in Vanilla JavaScript

#19

Post by creakingstairs » Sat, May 07, 2022, 1:41 PM UTC

kgbcia wrote: post #10

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…

i agree it's up to the browsers chromium , Safari , and Firefox to do the diff. But we might need a new meta tag or change to the Fetch API to tell them this html page should only update the elements that are different. Remember . It was discouraged because the back button broke. If you're developing a single page react app, I don't think you care about the back button.

> If you're developing a single page react app, I don't think you care about the back button.

You should though. One easy way is to use react-router. e.g. going to /profile renders the Profile component. Then navigating to /dashboard renders the Dashboard component. Pressing the back button will take you to /profile.

Another pet peeve of mine is people using internal react state when they should just use path or query params to make it transparent and easily sharable.

Re: TodoMVC App Written in Vanilla JavaScript

#20

Post by anonymoushn » Sat, May 07, 2022, 1:43 PM UTC

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…

it sounds sort of wild to expect there to be diffing! why do you have to generate a whole copy of the stuff instead of just telling the browser what changes to make? bonus: the existing apis instead of one that don't exist yet.