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

101–110 of 115 posts

Re: TodoMVC App Written in Vanilla JavaScript

#101

Post by BiteCode_dev »

qudat wrote: post #100

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…

Also:

- add time constraints, where you need to implement widgets that you could source from a JS framework ecosystem otherwise.

- in your 10 engineers, make it 5 juniors, 2 interns and 3 seniors comming from PHP, and make sure they write all the code in the same style, follow a congruent architecture, can find solutions to common problem, get easy onboarding, etc.

- request sub-routing, off-line mode, notifications, content udpated by multiple users and so on.

- put a big table in there with 10000 rows and ask your team it renders fast.

Re: TodoMVC App Written in Vanilla JavaScript

#102

Post by 1marc »

qudat wrote: post #100

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…

With some patterns they can follow, vanilla js does indeed scale so well that it becomes boring. There’s no longer any code to rewrite for the latest and greatest frameworks. No dependencies to manage. It just becomes almost too easy at some point, at least in my experience with many projects I’ve led.

I’ve made millions and millions for major brands, including my own company, and customers go “wow how is your site so fast!!” All. The. Time.

The biggest pressure I’ve found is from the engineers themselves. Not all engineers like to go counter culture and learn browser APIs and JavaScript. They would simply like to use what everyone else is using. They tend to argue against vanilla using canned arguments read off of framework websites that don’t apply much or aren’t even problems in the actual codebase.

:shrug:

Re: TodoMVC App Written in Vanilla JavaScript

#103

Post by eyelidlessness »

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.

> Cases where "UI should be a function of state" seem like a small sliver of all use cases.

Maybe not “should”, but it’s an incredibly helpful mental model, and I can think of very few cases it can’t model correctly. It’s so helpful a model that it’s gained traction in Rust, Swift, Kotlin, Dart, Go. It’s the ~only model in Clojure and and literally the foundation of Elm.

None of these cases, AFAIK, apply the model literally when they interface with inherently imperative APIs. They provide APIs expressing the model, and manage the imperative behavior on your behalf. This is ultimately how all functions in meaningful programming work. At the end of the day, allocating memory or displaying output is a side effect.

This is also how you can have custom renderers like those used in ink, three-solid, even React Native. The code is modeled as a declarative function of state, implemented as a set of imperative behaviors corresponding to state and dependency changes.

I’ve worked on contentEditable solutions in the past, probably more than most people who didn’t ultimately produce a library from the work (I went mad, literally angry at the complexity of making it a good UX, and gave up). I hope I never have that task again, but if I do… you can bet your ass I’d use a function of state model. It’s the only way I could reason about the problem without going mad.

Re: TodoMVC App Written in Vanilla JavaScript

#104

Post by eyelidlessness »

deergomoo wrote: post #95
recursive wrote: post #45

Earlier quoted context omitted.

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.

For what it’s worth, even using “vanilla” JS it’s generally much easier than it’s made out to be. It requires design discipline and knowing ahead of time what discipline to apply. But it’s pretty simple once you know it:

- the UI isn’t a source of truth, it’s a computed interface to it

- changes/interactions in the UI should update the source of truth, not other parts of the UI

- the source of truth is fully responsible for managing and notifying dependencies of relevant changes

Or much shorter: state and presentation are separate concerns. Once you have that, you can focus on the actual problems you’re trying to solve rather than the ones created by crossing underlying technology boundaries.

Re: TodoMVC App Written in Vanilla JavaScript

#105

Post by dimgl »

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…

Yep, you nailed it. I've been looking at low-JS and vanilla JS again recently given the amount of hype around these kinds of frameworks (and the perceived maturity of the browser).

It still has the same problems you describe. You worded it way more eloquently than I can.

Re: TodoMVC App Written in Vanilla JavaScript

#106

Post by dimgl »

danielskogly wrote: post #37

I wrote a TodoMVC App with React, Redux and SSR that works without JS enabled in the browser a while back, for those interested in that sort of thing :) Demo: https://todo-react-redux-noscript.herokuapp.com/ Repo: https://github.com/wishy-gift/todo-react-redux-noscript/ Talk (updated framework): https://m.youtube.com/watch?v=3yY-Z-X3xE4 Helpers to do your own stuff: https://www.npmjs.com/package/@wishy-gift/noscript

Thanks for sharing this. I have to admit, this is an absurd amount of code for a todo app. Is there a specific goal you had in mind when creating this? Are you trying to show the capabilities of SSR (or maybe Redux)?

Re: TodoMVC App Written in Vanilla JavaScript

#107

Post by wruza »

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…

This relieves the developer of keeping track of DOM state, as you only declare the render function once

A good part.

and after that you only need to manage state

A part where to change a[n].b.c:

React: you either split into unhealthy number of “components”, which are never reused and require tons of pass-through, or only manage state as a sequence of unnatural to js “reduce” operations.

Vue: give away your data to Vue, because once it hits `.data` it gets charged with properties incompatible with the entirety of js language.

Vue is essentially a separate programming language, which somehow managed to sell the manual transpilation to its users. React did the same being Haskell-like variant. The “upon native functionality” of this is equivalent to python3.dll being upon a native functionality of C++.

Most of your points still valid, I only wanted to unfold that “only manage state” bit. It’s sad that libraries like Mithril aren’t the default, and instead monstrosities like React are.

Re: TodoMVC App Written in Vanilla JavaScript

#108

Post by noahtallen »

recursive wrote: post #48
Philip-J-Fry wrote: post #44

Earlier quoted context omitted.

Yes... but that's the exact argument I'm making here. Unless you want to go through that pain, you need a framework. Whether that's Svelte without a VDOM or React with a VDOM. The entire point of these frameworks is that you can write complex UI in a declarative way. They both exist because writing it declaratively in pure JS leads to performance issues. But there's nothing stopping the browser implementing something…

I find the "pain" to be drastically overstated. See this HN post.

I mean, it’s clear that with a single view, it’s possible to manage this without too much trouble. But next to no apps are single views. And any project that has multiple people working on it is going to have multiple views and features which all interact in interesting ways. It’s definitely not overstated. Try writing a moderately involved app yourself in plain JS! It does get to be a pain, I’ve done it! By the time you finish, you’ll have likely created some level of abstractions, and invented yourself a nice new JS framework for yourself ;)

Re: TodoMVC App Written in Vanilla JavaScript

#109

Post by mmcnl »

wruza wrote: post #107
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…

This relieves the developer of keeping track of DOM state, as you only declare the render function once A good part. and after that you only need to manage state A part where to change a[n].b.c: React: you either split into unhealthy number of “components”, which are never reused and require tons of pass-through, or only manage state as a sequence of unnatural to js “reduce” operations. Vue: give away your data to Vu…

You have to manage state within the rules of the framework, that's true. But the hard part of programming usually isn't syntax. Who cares if it's a different language/paradigm? It's a simple language and I only have to say a few words. It's still orders of magnitude less complex (this is not an exaggeration) than rolling your own framework with vanilla JS.

I would encourage you to find out why React is popular and why Mithril isn't on the assumption that the world isn't crazy.

Re: TodoMVC App Written in Vanilla JavaScript

#110

Post by ghubcoder »

grabanski wrote: post #59
ricardobeat wrote: post #42

Earlier quoted context omitted.

The assignment (=) is missing from those const declarations, except for the first one; I guess they were hastily converted from function declarations to satisfy modern tastes.

Oops, yeah I just accepted a pull request from the community that broke my helpers module declarations. Just fixed it, thanks for noticing!

Thanks for sorting it.
Post reply on HN