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

Vanilla-todo: A case study on viable techniques for vanilla web development

github.com

Post reply on HN
Print view View original

121–130 of 154 posts

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#121

Post by megous »

Not separating the state from the DOM (more than necessary, that is - at the client/server boundary) makes a bunch of things much easier. You can just manipulate the DOM and the state stays with the DOM, so there's nothing to sync internally within the JS app. You only serialize from DOM and to DOM at the server API boundary. No need for the "rendering" in response to state changes. You just change the DOM intuitively, and that's that.

And that makes "vanilla" browser apps easier to write too.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#122

Post by xwdv »

austincheney wrote: post #3

It's amazing that a repository like this is even a thing. A demonstration that you don't need 3 million dependencies and a giant framework to build a simple application in the environment where a language was created to support.

I don’t see the point really. In the real world applications aren’t “simple”. They are complex.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#123

Post by austincheney »

xwdv wrote: post #122
austincheney wrote: post #3

It's amazing that a repository like this is even a thing. A demonstration that you don't need 3 million dependencies and a giant framework to build a simple application in the environment where a language was created to support.

I don’t see the point really. In the real world applications aren’t “simple”. They are complex.

In the real world most JavaScript developers cannot write original code at all.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#124

Post by xwdv »

austincheney wrote: post #123
xwdv wrote: post #122

Earlier quoted context omitted.

I don’t see the point really. In the real world applications aren’t “simple”. They are complex.

In the real world most JavaScript developers cannot write original code at all.

In the real world they don’t really have to. They aren’t building libraries.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#125

Post by austincheney »

xwdv wrote: post #124
austincheney wrote: post #123

Earlier quoted context omitted.

In the real world most JavaScript developers cannot write original code at all.

In the real world they don’t really have to. They aren’t building libraries.

Developers that can’t develop. What could go wrong?

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#126

Post by datagram »

earthboundkid wrote: post #118
morrvs wrote: post #21

Earlier quoted context omitted.

Original author here - thanks! Yes, ES5 is a huge pain. However, I believe 5% of users (see other comment) are not a joke for many apps. There's always the question of minimum critical APIs required: If you build a 3D or webcam app you can forget ES5 altogether, of course. > It’s a lot like using polyfills when needed. Never thought of it this way, thanks for that! As is state in the conclusion, the study would likel…

Like most people who use ES5, your code is broken in IE11 and you had no idea. :-) You use Object.assign(state, next) which does not work in IE11. Using ES5 is pretty much always a mistake in 2020.

Object.assign is polyfilled: https://github.com/morris/vanilla-todo/blob/9a27e850e15fddfe...

That being said, the page still didn't load properly for me when I actually tried it in IE11, but it's not because of Object.assign.

Nobody writes ES5 because they want to; many developers are still forced to support Internet Explorer for one reason or another.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#127

Post by acemarke »

Cthulhu_ wrote: post #37
nicoburns wrote: post #22

Earlier quoted context omitted.

React has been stable since ~2015, and there are no signs of that changing.

Disagree; the "done thing" in React has shifted since then (moving from class-based components and HOCs to functional components and hooks), and in the wider ecosystem, Redux is being abandoned in favor of more React native things like Context. While React apps in 2015 probably still work with the newest versions of React, you can't put a 2015 React dev in a 2020 project and vice-versa as if nothing's changed.

I can assure you that Redux is not "dead" or "being abandoned":

https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...

https://blog.isquaredsoftware.com/2020/10/presentation-state...

Sure, it's definitely _peaked_, because there's a lot of other great options in the React ecosystem these days. But, there's still plenty of good reasons to use Redux. And, with our new Redux Toolkit package and the React-Redux hooks API, "modern Redux" code is a lot different than what you've seen in the past, as shown in our new "Redux Essentials" tutorial:

https://redux.js.org/tutorials/essentials/part-1-overview-co...

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#128

Post by morrvs »

falcolas wrote: post #76
morrvs wrote: post #63

Earlier quoted context omitted.

Sorry :D nothing wrong with server-rendered HTML and forms for many use cases. Unfortunately, by the limits of connectivity, if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side at some point.

> if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side I'm not sure I personally agree with this blanket statement. Connection times can be, for a vast majority of users, measured in tens of milliseconds, giving us a pretty good budget for processing and rendering while still appearing to be "instantaneous" (100ms) or "…

I'm not an expert but I'm certain we aren't even close to providing this level of connectivity. Throttled data, sucky hotel wi-fi, underground tunnels, bad service in rural areas of e.g. Germany etc. are real, unfortunately.

You cannot hope to get enough uptime and guaranteed response time ranges for an app's interactions from any server; you will always get inferior UX to client-side rendering (which, in a way, has 100% uptime and guaranteed response times only bound by CPU/RAM/bugs in your code).

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#129

Post by dreamcompiler »

falcolas wrote: post #76
morrvs wrote: post #63

Earlier quoted context omitted.

Sorry :D nothing wrong with server-rendered HTML and forms for many use cases. Unfortunately, by the limits of connectivity, if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side at some point.

> if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side I'm not sure I personally agree with this blanket statement. Connection times can be, for a vast majority of users, measured in tens of milliseconds, giving us a pretty good budget for processing and rendering while still appearing to be "instantaneous" (100ms) or "…

Completely agree. I still build websites with server-side rendering and just enough JS for Ajax, which changes innerHTML and occasionally adds an element. They are astonishingly fast, and they still function if the client has JS turned off.

I remain convinced that for 90% of websites, using React is shooting a sparrow with a cannon.

Re: Vanilla-todo: A case study on viable techniques for vanilla web development

#130

Post by morrvs »

ilaksh wrote: post #114

Why does it have to be fully animated? I feel like 44k is a lot if it's just a sortable list with checkboxes. I saw a draggable package on mom that is less than 2k. Does Vanilla mean we can't use npm or we pack or browserify or anything?

It does not have to be. However, animations greatly contribute to UX, and are an interesting cross-cutting concern to implement (with any tech).

Remember that 44K is unminified, unoptimized, with considerable duplication, and includes HTML, CSS, JS, and SVG icons.

Post reply on HN