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

91–100 of 154 posts

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

#91

Post by d_burfoot »

> Naively re-rendering a whole component using .innerHTML should be avoided as this may hurt performance and will likely break important functionality such as input state, focus, text selection etc. which browsers have already been optimizing for decades.

I think this statement deserves some serious scrutiny. In many cases the performance hit may not be relevant or noticeable. I know this because I've been very productively using the following approach to build dynamic webapps for my personal use:

1. Compose HTML strings using Javascript, especially with string interpolation

2. Slap the resulting strings into div/span elements with innerHTML= statements.

This approach results in extremely clean and simple code - much cleaner than the OP's code in my view. I have never noticed any kind of performance issues, the updates are always instantaneous. I don't know what the author means by breaking functionality like text selection and focus, but it's never been relevant for me.

For an example of the coding style, see the reDispActiveTable in this code, which draws a table of TODO list items with some operations like edit/delete/mark complete. https://github.com/comperical/WebWidgets/blob/main/gallery/m...

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

#93

Post by morrvs »

spark85 wrote: post #68

Are Web Components ( https://developer.mozilla.org/en-US/docs/Web/Web_Components ) considered to be a library/framework? If not have you considered trying to update the repo to use them

No, I'd consider them a standard and a candidate for implementing the case study. When I started the study I was thrown off by this: https://caniuse.com/?search=components - and very huge polyfills. In hindsight I'm not sure if I dismissed WC too quickly.

This is probably thin ice, especially since I've never built anything with WC, but they always seemed slightly over-engineered. I will try to learn about WC a bit more and maybe elaborate on my reasoning here.

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

#94

Post by eliseumds »

d_burfoot wrote: post #91

> Naively re-rendering a whole component using .innerHTML should be avoided as this may hurt performance and will likely break important functionality such as input state, focus, text selection etc. which browsers have already been optimizing for decades. I think this statement deserves some serious scrutiny. In many cases the performance hit may not be relevant or noticeable. I know this because I've been very produ…

That's what OP means: https://codesandbox.io/s/elastic-rubin-hxpcw?file=/src/index...

And that's why reconciliation algorithms became so popular. You can't be serious when you say that losing input focus and text selection have never been relevant to you. Basically, dealing with the internal state of components down the tree becomes a nightmare.

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

#95

Post by morrvs »

d_burfoot wrote: post #91

> Naively re-rendering a whole component using .innerHTML should be avoided as this may hurt performance and will likely break important functionality such as input state, focus, text selection etc. which browsers have already been optimizing for decades. I think this statement deserves some serious scrutiny. In many cases the performance hit may not be relevant or noticeable. I know this because I've been very produ…

You bring up an interesting point. I intentionally used "may" in that statement as using .innerHTML can be both effective and performant enough (and a lot simpler).

A couple possible problems off the top of my head:

1. CSS transitions won't work if you re-render a complete chunk of HTML instead of toggling a class.

2. , , , etc. may lose focus or even data on re-render (e.g. while filling out a form).

3. Text selection may be reset on re-render.

4. If you don't use event delegation, event listeners may need to be reattached.

I agree that for raw display .innerHTML may be sufficient, but it's surely not in general. That would make React almost irrelevant, by the way, which would be a huge surprise.

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

#96

Post by _the_inflator »

sfrinlan wrote: post #5

I don't know who originally said it but "If you're not using a framework, you're building a framework". This repo even has the following caveat: (2) These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. That said, I don't hate it. For quite some time, I've taken the stance that a web development team ne…

> adopting an established valid opinion to guide the team's development

Different requirements allow for different settings. Coming from an Enterprise Application background, I found this being more often the case or the only case. Working with different teams, developer fluctuation, different time zones, different skill sets, a framework guides the development process far better. Vanilla JS is something that should be avoided in team setups. There is too much mental overload that is usually not justified by the benefits. It is like deliberately choosing assembler language when Java or C# would do the job better. Frameworks got a bad rep. For me, they are tools that should be used.

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

#97

Post by nicoburns »

hackerfromthefu wrote: post #80
nicoburns wrote: post #35

Earlier quoted context omitted.

How much of an ecosystem do you really need? For me the key component are a state manager (e.g. mobX or Redux) and a Router (e.g. React Router). React Router has indeed been quite unstable, but that's gotten a lot better over the last couple of years. But React and Redux have both been super stable.

As a consultant who often sees existing systems in enterprise environments, react apps often have dozens of additional packages. And the churn on these packages is significant. React project in the wild seems to exist in two modes from what I can see, the constantly tended garden, or the write and move on and leave it to someone else to rewrite in future (otherwise known as write only, or abbreviated to perl). /s

> react apps often have dozens of additional packages. And the churn on these packages is significant.

IMO that's just poor engineering and not an inherent problem with React. The app I inherited at my current job had many such packages. And we have indeed had to update/replace some of them. However most of them were implementing functionality which could be trivially replicated in "plain react" so we've mostly replaced them with simple internal components and are not anticipating having the same problem in future.

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

#98

Post by nicoburns »

hackerfromthefu wrote: post #79
Cthulhu_ wrote: post #37

Earlier quoted context omitted.

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.

and in the real world react apps use countless npm packages, which get regularly deprecated as react versions move forward .. the real world churn in react land is most unfortunate

> in the real world react apps use countless npm packages

This is often the case in practice. But it's a pretty easy problem to avoid. Usually those packages simply aren't necessary in the first place.

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

#100

Post by X6S1x6Okd1st »

shams93 wrote: post #40
madoublet wrote: post #20

Earlier quoted context omitted.

Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are constantly re-writing completely valid and working code to keep up with the latest version of the framework. The JS language itself, on the other hand, seems to be very stable with long deprecation cycles and steady improvements. So, it is much easier to build on.

Organizations love the churn because they can get away with age discrimination lots of well qualified devs are left out to starve to death while constant churn hides a system designed to filter out the most experienced.

That's a very strong statement, do you have anything to back that up?
Post reply on HN