For me, the best kind of "moat" (tbh I hate that word, since it specifically implies needing to design (...scheme...) and engineer some kind of user lock-in, which is inherently user-hostile) would be staying aggressively on the forefront of DX. More important than feature churn, making it polished and seamless and keeping a smile on my face as I work is the best kind of "moat."
It requires constant attention and vigilance, but that's better for everyone than having some kind of "moat" that lets them start coasting or worse— lets them start diverting focus to features that are relevant for their enterprise sales team but not for developers using the software.
Companies really should have to stay competitive on features and developer happiness. A moat by definition is anti-competitive.
I feel this with every fiber of my being. I used to do a TON of front-end work, some of it quite cutting edge, delivering highly performant user experiences in the browser that had previously been only thought possible in a native app. Back in like 2009-2015. I was deeply connected with the web standards fundamentals and how to leverage them mostly directly.
I detoured into heavier focus on backend work for quite a while, concurrent with the rise of React, and watched its rise with suspicion because it seemed like such an inefficient way to do things. That, and JSX's limitations around everything having to be an expression made me want to gauge out my eyes.
Still, React pushed and laid the foundation for some really important paradigm shifts in terms of state management. The path from the old mental models around state to a unidirectional flow of immutable data... re-learning a totally new mental model was painful, but important.
Even though it's been chaotic at times, React has delivered a lot of value in terms of innovation and how we conceptualize web application architecture.
But today, when you compare it to something like SolidJS, it's really clear to see how Solid delivers basically all the same benefits, but in an architecture that's both simpler and more performant. And in a way that's much easier to organize and reason about than React. You still get JSX, server components, reactive state management (actually a MUCH better and cleaner foundation for that) and any React dev could move to Solid with fairly little mental re-wiring of the neural pathways. It doesn't require you to really change anything about how you think about application architecture and structure. It just basically does everything React does but better, faster, and with drastically smaller bundle sizes.
Yet I still have to begrudgingly use React in several contexts because of the industry-wide inertia, and I really wish I didn't have to.
> It just basically does everything React does but better
SolidJS still has some major pain points; the one I found was not knowing whether a prop was a signal or needed to become one. The type system doesn't help much. In React, you know for sure that if your reference changes, the component reading that reference as a prop will re-render. In Solid, it's less clear whether the update will be observed.
isLoading should be a boolean; it will maintain referential equality across renders and not cause a re-render unless it is an actual edge from false to true or vice versa.
what? what does what you said have anything to do with what I said? how does "data flowing down" now related to the use effect dependency cycle? are you new to programming?
> Yet I still have to begrudgingly use React in several contexts because of the industry-wide inertia, and I really wish I didn't have to.
I think you'll find a lot of people begrudgingly have to work and really wish they didn't have to. That means using what they know, which means React. Which I totally get. People want to spend time with their kids, hobbies etc. Worst case, they might be caring for others, like their elderly parents.
You don’t have to! I wonder what you think of this framework my company (mostly me) developed over the last decade, I am open sourcing it under MIT license: https://github.com/Qbix/Q.js
The frontend would be so much better if Eich had shipped scheme.
ES6 wouldn’t have been needed. CSS-in-JS would have become standard decades ago. HTML would have almost disappeared too because parsing s-expressions would have been native. JSON would never been invented either due to S-expr.
In short, everything about the modern web would have appeared decades sooner and been more consistent.
Natural language has parentheses. Math notation has those and different kinds of brackets, too. But tell me, what language has closing tags? A language for parrots?
Only half joking, it's same principle as how indentation-based Python ate world, while languages with `begin` and `end` keywords like Ruby and Pascal are hardly to be seen these days
This is beautiful! I love this so much, as it makes it so simple and intuitive to drop into a sense of curiosity, exploration, serendipity, scanning around, seeing what catches the eye, zooming in and out.
It kind of recaptures part of the intangible sense of flipping through the old physical pages to see what catches the mind's interest. This feels substantively different from the current way that we discover and stumble upon things in the modern web and especially mobile app ecosystems with infinite scroll and algorithmically curated feeds.
My working theory, which I hold quite confidently, is that anything that doesn't test well with new users in usability testing focus groups or A/B testing eventually gets the axe. But the people conducting that testing are - intentionally or unintentionally - optimizing for the wrong metric: "how quickly and easily can someone who has never seen this app before figure out how to do this action." That's the wrong thing to optimize for at a macro scale. It might make your conversions go up for a while, but at a long term cost of usability, capability, and discoverability that enrages the users that you want to convert into advanced, loyal, word of mouth evangelists for your app because they love it.
When people who are not thinking in that bigger-scale, zoomed-out, societal-level perspective conduct A/B testing or usability testing in a lab or focus group setting, they focus on the wrong metrics (the ones that make an immediate, short-term KPI go up) and then promote the resulting objectively worse UX designs as being evidence-based and data-driven.
It has been destroying software usability for the last 20 years and doing a deep disservice to subsequent generations who are growing up without having been exposed to TRULY thoughtful UX except very rarely.
