Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

At peak jquery, I argued successfully for storing the metadata on DOM, because then you have a system of record, upon which you can build a straightforward source of truth. React does a ton of work to solve that architectural puzzle another way.

The thing I have run into over and over again is that when we try to pretend the system is Y when it is in fact X, inevitably the impedance mismatch results in 1) bugs that should be easy to reason about but are difficult to fix, and 2) a form of pulling the ladder up behind you.

If I want to continue to work on interesting things I have to be able to carve out chunks of my code to gift to #3 on the bus number list, so I have the bandwidth to double down on some other topic or expand into another.

I know which side my bread is buttered on. Many don’t. Which is why I have a more consistent supply of mentees than many of my peers.



Data comes from the server as JSON. Data comes from the user as DOM events and changes. There's always going to be an impedance mismatch.

The DOM API sucks, so React et al went all in with state-as-objects. IMO it was the right call.


I just don't think DOM->JSON->server->microservice->DB->microservice->server->JSON->DOM is sustainable long term. It's had a good run, but it's a big part of the reason I'm looking at Phoenix for a personal project. React is predicated upon solving the wrong problem.

Talk about impedance mismatches.


I'm not sure switching to DOM->JSON->server->microservice->DB->microservice->server->DOM will make much of a difference.


Complexity is usually quadratic or factorial. Only a tiny number of systems are logarithmic. 20% reduction in parts can often be a 40-70% reduction in cognitive load.

But the funny thing with fractions is that if go above a threshold and come back from the brink, the path back is a smaller number than the path out. So if you go from 8 to 10 steps that's 25% worse and if you undo that bad decision you are getting 20% better. So you want to be careful to compare sustainable to unsustainable and not the other way around, if you follow me.


> I argued successfully for storing the metadata on DOM

Who did you convince?


A team working on an AJAX webapp that typically was meant to comfortable manage around 1000 blocks of state at a time. Somewhere on the order of 6-10 pieces of data per block (Which we just changed as a unit of work because 1000 was already hard enough). And when you're dealing with 10^3 you need a couple of different ways to visualize the same data or you're getting nowhere, so we had one or two other views that dealt with different levels of detail.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: