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

Virtual DOM is pure overhead (2018)

svelte.dev

Post reply on HN
Print view View original

181–190 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#181

Post by jsyolo »

pweissbrod wrote: post #126
com2kid wrote: post #105

Earlier quoted context omitted.

Svelte is so insanely lightweight, I think it is a great counter argument to a lot of the SPA hate. And honestly, most of the weight in modern websites comes from analytics and tracking tools. I've made insanely performant SPAs that work well on low budget hardware. My personal phone is 5 years old, if code I write doesn't perform flawlessly on it I'm not going to ship it to customers! Heck my personal dev laptop is…

By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. You may already have this but you may not. In most cases you must choose a framework for routing. Also a framework for state management. You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. More often than not you will find yourself including…

What backend tech do you like to pair HTMX with?

Re: Virtual DOM is pure overhead (2018)

#182

Post by mrtranscendence »

AtlasBarfed wrote: post #137
com2kid wrote: post #105

Earlier quoted context omitted.

Svelte is so insanely lightweight, I think it is a great counter argument to a lot of the SPA hate. And honestly, most of the weight in modern websites comes from analytics and tracking tools. I've made insanely performant SPAs that work well on low budget hardware. My personal phone is 5 years old, if code I write doesn't perform flawlessly on it I'm not going to ship it to customers! Heck my personal dev laptop is…

I wish there was a "works for Pentium III" label that would help indicate that the app's usability hits necessary minimums on a 1Ghz Pentium III computer. IMO that would be a good optimization floor for avoiding the hidden monstrosity of electron apps and that type of stuff. If your McCrud app can't be responsive on a baseline 1Ghz PIII with 1GB of RAM, then there needs to be some sort of shame pushback. Moore's law…

Why Pentium III? That's nearly 25 years old. You couldn't run Windows 10 on such a processor, let alone a modern browser, and a $200 mobile phone would beat it in benchmarks. Surely you can have a higher floor than that.

Re: Virtual DOM is pure overhead (2018)

#183

Post by pweissbrod »

jsyolo wrote: post #181
pweissbrod wrote: post #126

Earlier quoted context omitted.

By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. You may already have this but you may not. In most cases you must choose a framework for routing. Also a framework for state management. You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. More often than not you will find yourself including…

What backend tech do you like to pair HTMX with?

That's the thing. It doesn't really matter. It's sort of like asking what backend tech you pair with jQuery

Re: Virtual DOM is pure overhead (2018)

#184

Post by toastal »

AtlasBarfed wrote: post #137
com2kid wrote: post #105

Earlier quoted context omitted.

Svelte is so insanely lightweight, I think it is a great counter argument to a lot of the SPA hate. And honestly, most of the weight in modern websites comes from analytics and tracking tools. I've made insanely performant SPAs that work well on low budget hardware. My personal phone is 5 years old, if code I write doesn't perform flawlessly on it I'm not going to ship it to customers! Heck my personal dev laptop is…

I wish there was a "works for Pentium III" label that would help indicate that the app's usability hits necessary minimums on a 1Ghz Pentium III computer. IMO that would be a good optimization floor for avoiding the hidden monstrosity of electron apps and that type of stuff. If your McCrud app can't be responsive on a baseline 1Ghz PIII with 1GB of RAM, then there needs to be some sort of shame pushback. Moore's law…

Works on a KaiOS feature phone support would be a relevant metric today with similar goals that you mention. They explicitly state in their docs that React will be too heavy for your app.

Re: Virtual DOM is pure overhead (2018)

#185

Post by shortcake27 »

pweissbrod wrote: post #126
com2kid wrote: post #105

Earlier quoted context omitted.

Svelte is so insanely lightweight, I think it is a great counter argument to a lot of the SPA hate. And honestly, most of the weight in modern websites comes from analytics and tracking tools. I've made insanely performant SPAs that work well on low budget hardware. My personal phone is 5 years old, if code I write doesn't perform flawlessly on it I'm not going to ship it to customers! Heck my personal dev laptop is…

By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. You may already have this but you may not. In most cases you must choose a framework for routing. Also a framework for state management. You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. More often than not you will find yourself including…

> By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application.

No you don’t.

> In most cases you must choose a framework for routing. Also a framework for state management.

I don’t understand this argument. React gives the developer this freedom by design. If you want a framework that has all of these decisions made for you, they exist.

> You also dedicate to duplicating validation and security trimming logic both on the client side and the server side.

I’ve been validating on the frontend for 15 years, long before I worked on an SPA. It has never been necessary but it provides a better experience. If you don’t like this, you can still let the server do all the validation. There is nothing about an SPA that enforces client-side validation. And you’re wasting your time if you’re doing security filtering on the the frontend.

> Also the requirement for unit testing on the front end is common. Which brings in the need for things like jest and enzyme.

“Grr this paradigm allows me to test my code, I hate it!”. Seriously, we’re now able to write unit tests which were previously impossible. How is this a bad thing? Also Enzyme hasn’t worked since React 17, I now use RTL which asserts user behaviour - super nice.

> Because you have a virtual DOM this is now a security risk.

What?

> You must build a component which duplicates the user interface which already exists.

How is this any different to a non-SPA? Regardless of technology you can’t just arbitrarily lift interfaces from unrelated applications and inject them into your application without a bit of work.

> If the user interface needs to be shared among many applications you must build a commons code base to host your components.

Again, how is this any different from a non-SPA? You UI isn’t going to magically share itself between applications just because you don’t have an SPA.

I’ve worked on all types of applications and I don’t think SPAs should be the defacto approach, but I really feel you’re clutching at straws with all of your arguments.

Re: Virtual DOM is pure overhead (2018)

#186

Post by c-smile »

ttfkam wrote: post #178
c-smile wrote: post #140

Earlier quoted context omitted.

To make it even closer to Svelte, Sciter has native signal() implementation, so let bottles = signal(0); function Beers() { return 1}>{bottles.value} bottles of beer } document.body.append( ); That can be updated by simply changing signal: bottles.value = 42; // Party time! Note: this does not require any preprocessors or precompilations.

Let's compare lines of code, because more lines invariably leads to more bugs. Contents of Beers.svelte: export let bottles = 99; {#if bottles > 0} --bottles}> {bottles} bottles of beer on the wall {:else} No more bottles of beer on the wall {/if} Then to use it: import Beers from './Beers.svelte'; No knowledge of Reactor's existence needed let alone the library's "signal" function. No functions needed at all. No bes…

In Sciter you do not need any preprocessor at all, not even JS in your HTML:

    
      div.beer {
        prototype: Beer url(/components/beer.js);
      }
After that div.beer element will be instanceof Beer. In this case class Beer used as a [Web-alike] component.

Re: Virtual DOM is pure overhead (2018)

#187

Post by ttfkam »

hbrn wrote: post #162
ttfkam wrote: post #112

Earlier quoted context omitted.

Yep, Solid is among the fastest but requires more cognitive overhead. Svelte requires very little over and above HTML and JS while still being closer to Solid in performance than React, Vue, or Angular. And the latest interactions of React and its ecosystem have both high cognitive overhead AND lackluster speed. At least Angular is opinionated. React is just a YOLO ball of yarn for large codebases.

Can you expand a bit more on cognitive overhead in Solid? What are the examples?

JSX. This was never zero cognitive overhead as compared to plain HTML. Folks have simply had 10 years of practice with their Stockholm Syndrome.

With Svelte, you see a script tag with 99% plain JS, some HTML with some basic control and binding syntax, and a style tag with 100% plain CSS/SCSS.

No createSignal(…) with [foo, setFoo]. No props objects. No onCleanup(…) handlers. No createEffect(…) to track reactivity. No render(…) function just to show some HTML. No string template literals to use the framework. No worrying about when to use createMemo(…) or not. Nothing more than a $ prefix to use a store.

Solid (and React et al) is to Svelte as vanilla DOM is to JQuery.

Re: Virtual DOM is pure overhead (2018)

#188

Post by hbrn »

stillkicking wrote: post #150
PaulHoule wrote: post #138

Earlier quoted context omitted.

A classic example of: "you had one problem, now you have ten problems". That's fine if you aren't writing any unit tests or trying to fix bugs with the debugger. If context are in use you might have some 'simple' system with 10 components that shows 150 components in the React component viewer most of which are worthless context blocks that are just there to waste your attention and probably the CPU and memory of you…

>React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways So let's first back up and recognize that this earlier statement was flat out wrong. React does provide a systematic answer for this. Second, not only does it have a systematic answer, but it memoizes quite well because React will not re-render children if the `children` prop is identical to the previous ren…

> So let's first back up and recognize that this earlier statement was flat out wrong. React does provide a systematic answer for this.

Context was never a systematic answer. Even today the docs say:

  Apply it sparingly because it makes component reuse more difficult.

  If you only want to avoid passing some props through many levels, component composition is often a simpler solution than context.
https://reactjs.org/docs/context.html#before-you-use-context

And IIRC older docs would be even more harsh at recommending not to use context.

Re: Virtual DOM is pure overhead (2018)

#189

Post by toastal »

vbezhenar wrote: post #149

I can't trade TSX for any text templates. Being able to write tags and having them syntax-checked with types support is indispensable. I wish that those frameworks embrace TSX rather than trying to drag users to the dark past.

I'd rather type checked functions that don't have to futz XML syntax and unexpected incompatiblities with HTML while superficially looking similar. A lot of compile-to-JS languages that don't have a the C-like syntax, the results are highly legible which being more condense and not require a separate parse/compile step.

Re: Virtual DOM is pure overhead (2018)

#190

Post by mrtranscendence »

randomdata wrote: post #29
traverseda wrote: post #7

Earlier quoted context omitted.

Serious answer? SEO and accessibility. HTML lets search engines crawl pages and screen readers read pages (which can often be a legal requirement). If we're rethinking the web stack I'd advocate for htmx with wasm-based web components for more complicated stuff like if you needed to polyfil in some new image format, or run a terminal emulator, or do webrtc calls with your own fancy custom noise reduction algorithm. Y…

> Serious answer? SEO and accessibility. How is WASM less accessible than Javascript? Are crawlers parsing minified and obfuscated Javascript sources and deriving meaning from them in a way they couldn't from WASM code?

No, as far as I know they render the page as part of the crawling. I'm not a web developer but I don't see why that couldn't be done with WASM.

Don't know about screen readers. I'd be surprised if they weren't using the live DOM, though.

Post reply on HN