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

211–220 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#211

Post by namelosw »

DonHopkins wrote: post #184
namelosw wrote: post #67

Earlier quoted context omitted.

React is more like 'Lambda the Ultimate Web Component'. A component is almost a function returns element. Expanding a component is like calling a function and give it the property. So you can have some abstract common behavior in HOC f and g, then you can have HOC `h = compose(f(g))`. A quick comparison with Angular: @Component({template, style}) seems composable if we stretch a lot. But why make template and style i…

We can only hope that Guy Steele swoops in and saves the day by implementing React in hardware! https://news.ycombinator.com/item?id=8860722 The Great Quux's Lisp Microprocessor is the big one on the left of the second image, and you can see his name "(C) 1978 GUY L STEELE JR" if you zoom in: http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c... Design of a LISP-based microprocessor https://dl.acm.org/citat…

Also according to Wikipedia[0] Brendan Eich was supposed to create 'Scheme in browser' but in the end it became scheme with Java syntax. I always wonder if it was real 'scheme in browser' the web would advanced faster, at least S-expression is good at expression HTML. Therefore we wouldn't have to wait JSX until 20 years later...

[0] https://en.m.wikipedia.org/wiki/Brendan_Eich

Re: Virtual DOM is pure overhead (2018)

#212

Post by imtringued »

mercer wrote: post #206
Udik wrote: post #198

Earlier quoted context omitted.

> he thing that changed to make frontend development improve dramatically was hash based routing with ajax... I think that what's changed is simply that people realized that it's way less messy to use the backend only as a data source (with ajax calls), and leave everything else to the frontend. The cognitive overhead of having the server producing html with some implicit state, then updating that state interactively…

While I agree in theory, in practice I find that the frontend still has all sorts of warts that don't quite make it a great solution (yet). I mean, it's better than having to maintain both server- and client-side logic and state (and having to sync all that), and definitely better than the days where we also had to manage DOM diffing manually. But I still get headaches from the NPM/node ecosystem, the build steps, ha…

Keeping the view state in the server is what Java Server Faces did and trust me you don't want to repeat that same mistake.

Re: Virtual DOM is pure overhead (2018)

#213

Post by namelosw »

xfer wrote: post #148
namelosw wrote: post #138

Earlier quoted context omitted.

You can't expect most code bases use JSX as template. It's not even praiseworthy if the framework provide every possible choices. Just like you can do anything in C++, but in practice it's a terrible language to work with. For class part I'm sure it's just whatabouism... And for expressions it's not praiseworthy to put in the template, but my point is why not reusing JavaScript semantics rather than implementing you…

> Just like you can do anything in C++, but in practice it's a terrible language to work with. It definitely beats working with JS for me.

Haha fair enough, especially if you consider the book 'JavaScript' minus 'JavaScript the Good Part' meme.

Re: Virtual DOM is pure overhead (2018)

#214

Post by brylie »

JMTQp8lwXL wrote: post #117
brobdingnagians wrote: post #55

Earlier quoted context omitted.

I love Vue.js. I've never really caught onto the JSX stuff. If you have ".Vue" files then you get nice separation of the template html, methods, and the scoped styling. The Javascript syntax is pretty straightforward, and the templates just add nice directives like v-if, v-for, etc. I think it look pretty clean and is fairly easy for JS developers to pick up. Integration into a project is pretty straightforward as we…

I've never understood how people view the separation of template, styles, and business logic into separate files as simpler. Now, to work on a single component, I need to open three files in my editor, instead of one.

The "separate files" argument is a red herring. It is really about separate "mindsets" or "modes of thinking".

In effect, JavaScript logic tends to be procedural/imperative, while templates allow declarative semantics, and styles are nearly a 2.5D constraint language. "Separation of concerns" here means only having to think in a particular mode, rather than blending all of those modes of thought into a single eyespan.

Notably, Vue allows for single-file components, while preserving the familiar and intentionally designed separation of declarative (HTML), imperative (JavaScript), and aesthetic (CSS) code.

Re: Virtual DOM is pure overhead (2018)

#215

Post by mercer »

imtringued wrote: post #212
mercer wrote: post #206

Earlier quoted context omitted.

While I agree in theory, in practice I find that the frontend still has all sorts of warts that don't quite make it a great solution (yet). I mean, it's better than having to maintain both server- and client-side logic and state (and having to sync all that), and definitely better than the days where we also had to manage DOM diffing manually. But I still get headaches from the NPM/node ecosystem, the build steps, ha…

Keeping the view state in the server is what Java Server Faces did and trust me you don't want to repeat that same mistake.

Here's an interesting response from Elixir's creator (and contributor to LiveView) specifically about JSF:

https://elixirforum.com/t/phoenix-liveview-is-now-live/20889...

I don't know JSF so I can't really argue this point, but I'd really love to hear what you think about the argument Jose put forward and where you might disagree!

Re: Virtual DOM is pure overhead (2018)

#216

Post by hyperdimension »

DonHopkins wrote: post #176
nailer wrote: post #158

Earlier quoted context omitted.

Makes sense, you don't want to write your own tests for handling zero.

Teach the Controversy [TM]! https://en.wikipedia.org/wiki/Parity_of_zero#Education Claims made by students: "Zero is not even or odd." "Zero could be even." "Zero is not odd." "Zero has to be an even." "Zero is not an even number." "Zero is always going to be an even number." "Zero is not always going to be an even number." "Zero is even." "Zero is special." https://en.wikipedia.org/wiki/Teach_the_Controversy

Just so you know (not just for this comment)--you are my favorite HN user. Everything you post is either funny, quirky, or extremely interesting (mostly all of the above).

Re: Virtual DOM is pure overhead (2018)

#217

Post by mercer »

hyperdimension wrote: post #216
DonHopkins wrote: post #176

Earlier quoted context omitted.

Teach the Controversy [TM]! https://en.wikipedia.org/wiki/Parity_of_zero#Education Claims made by students: "Zero is not even or odd." "Zero could be even." "Zero is not odd." "Zero has to be an even." "Zero is not an even number." "Zero is always going to be an even number." "Zero is not always going to be an even number." "Zero is even." "Zero is special." https://en.wikipedia.org/wiki/Teach_the_Controversy

Just so you know (not just for this comment)--you are my favorite HN user. Everything you post is either funny, quirky, or extremely interesting (mostly all of the above).

To add some positivity, I'll add that I'm also a fan :).

Re: Virtual DOM is pure overhead (2018)

#218

Post by austincheney »

citeguised wrote: post #210
austincheney wrote: post #200

Earlier quoted context omitted.

> but I wonder how difficult it is. Its not if you have some basic understanding how the code actually works. > but I find it a bit hard to imagine doing an actual app with vanilla JS. Try it. It will blow your mind how simple it is and how little overhead it requires.

I went from developing simple server-rendered websites enhanced with a bit jQuery straight to React-style JS. I'm interested in studying the source of less or more complex JS-apps, that were developed without SPA-Frameworks. One I'd like to see would be Construct3, but alas it's not open-source. I'd very much appreciate links and hints!

You can look at my SPA that maintains state perfectly well and persistently without any framework. It isn't hard, but you would have to be willing to write original code.

https://prettydiff.com/

All of the UI is defined here: https://github.com/prettydiff/prettydiff/blob/master/api/pre...

Re: Virtual DOM is pure overhead (2018)

#219

Post by rocqua »

DonHopkins wrote: post #176
nailer wrote: post #158

Earlier quoted context omitted.

Makes sense, you don't want to write your own tests for handling zero.

Teach the Controversy [TM]! https://en.wikipedia.org/wiki/Parity_of_zero#Education Claims made by students: "Zero is not even or odd." "Zero could be even." "Zero is not odd." "Zero has to be an even." "Zero is not an even number." "Zero is always going to be an even number." "Zero is not always going to be an even number." "Zero is even." "Zero is special." https://en.wikipedia.org/wiki/Teach_the_Controversy

I mean, zero is so even, it is not even odd!

Re: Virtual DOM is pure overhead (2018)

#220

Post by DigitalSea »

This is why I use Aurelia. It's a Javascript framework many here have probably never heard of or used, it debuted in 2015 and I have been working with it for four years now. Sadly Aurelia debuted at the height of the React hype and soon after, Vue hype.

Rob Eisenberg (the man in charge of the Aurelia project) had the right idea straight out of the gate. A reactive binding and observation system that worked like a virtual DOM (isolated specific non-destructive DOM operations) without the need for an actual virtual DOM. Which allows you to use any third-party library without worrying about compatibility or timing issues with the UI.

This is one area where React falters, at least when I used it. third party libraries clashed with the virtual DOM. When you start introducing abstractions to solve imaginary problems caused by improperly written code (the myth of the DOM being slow) you introduce issues you have to battle later on as your application scales.

Post reply on HN