Live data from Hacker News

Second-Guessing the Modern Web

macwright.org

461–467 of 467 posts

Re: Second-Guessing the Modern Web

#461

Earlier quoted context omitted.

You don't need a VDOM to use a buffer to batch changes. A VDOM is a buffer that comes with a huge amount of overhead vs an ordinary sequential buffer of DOM manipulation commands. VDOM is an optimization that allowed react to be fast enough to work, it can never be faster than direct dom manipulation.

Yes. You are right. Vdom is useless.

VDOM isn't useless. It's basically an optimized immutability helper. React wouldn't have been feasible without it.

But mutating the data directly is always going to be faster.

If you want to operate at a level of abstraction where you can ignore mutability and say rerender an entire huge ul every-time a single li changes, then using a VDOM to calculate the diff so you can only replace the single li is going to be faster than replacing the entire ul directly in the DOM. In many cases this is fast enough and so you get to program at a that higher level of abstraction.

However, if you have code that just directly replaces the innerHTML in the single li that changed, the VDOM can never be faster than that. Because it has to do that as well as calculate the diff to find which li it should change.

In essence Svelte just runs more of its abstraction optimization techniques at compile time instead of at runtime.

Re: Second-Guessing the Modern Web

#463

I strongly support this sentiment. I’ve recently come to the conclusion (after building a non-trivial react app from scratch) that the optimal use case is in a rails/django/go/whatever app that only uses react to handle front end state for the hairy components while the lion’s share is handled by the server.

What would that look like in practice. Would you write 95% of the basic crud stuff as server side rendered then just have the React or Vue component for the really complex UI stuff? Would there be downsides having the mix of languages (assuming your backend language is not JavaScript) ?

most of the page is server rendered. The hairy bits (eg. complex forms, super interactive components) are react and they maintain their own state. There might be downsides but they're probably not worse than writing a bunch of jQuery.

Re: Second-Guessing the Modern Web

#464
post #457

Earlier quoted context omitted.

I'm not a React expert, but I wonder how do you interpret this by Dan Abramov? This is where I got my information about hooks before trying them out: React doesn’t offer a way to “attach” reusable behavior to a component (for example, connecting it to a store). If you’ve worked with React for a while, you may be familiar with patterns like render props and higher-order components that try to solve this. But these pat…

Right, it's not that managing state was hard it's that sharing the logic to manage it was hard. Hooks are additive in that way -- it's offering you the ability to re-use your stateful React logic in the same way you can re-use your declarative JSX.

Thanks for the explanation. React is a great solution for many problems.

Re: Second-Guessing the Modern Web

#465

Earlier quoted context omitted.

You end up dupe your layout page everywhere and have a hard time update all of them if designer changed their mind. Or you could use some template system to do that… but if you need to use template, why not use react(or something like that) anyway?

Because Rails, Symphony, Django, Phoenix or whatever does the job in the preferred language of the developer/team and often has more batteries or better tooling included.

I bet those are not a Front end's preferred language and you end up need JavaScript anyway if you need some extra client form handling. Now you use two language to do one thing and made it more difficult to be maintained.

Re: Second-Guessing the Modern Web

#466

Earlier quoted context omitted.

I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on: > There are a lot of problems for which I can't see any concrete benefit to usi…

Serious question: Is this really a problem with web developers? Or is it with product managers who demand SPA like behavior?

For all the talk of "resume driven development" I think most developers - unless they are playing around with side projects and non-essential experimental stuff - prefer to do the simplest thing that will get the job done and keep the site maintainable, and the reason they resort to more complex and advanced frontend solutions is due to onerous requirements from stakeholders for more and more intricate and complex UI. It's another question entirely whether this more intricate and complex UI actually delivers business value or provides a better experience for the end users, but that question is above the developers' pay grade.

Re: Second-Guessing the Modern Web

#467

Earlier quoted context omitted.

Curious if you (or anyone else) have used the ios and/or Android adapter for mobile? Seems like the repos are getting stale. Getting SPAness on web and mobile apps for free would be the holy grail. Basecamp claims it works great for their mobile app.

The Android turbolinks version 1 adapter is now deprecated but a version 2 is meant to be coming soon. I believe it's going to come out after Basecamp's new product named Hey is released shortly.

I am waiting for it
Post reply on HN