A tale as old as time: hubris. A successful system is destined to either stop growing or morph into a monstrosity by taking on too many responsibilities. It's hard to know when to stop.
React lost me when it stopped being a rendering library and became a "runtime" instead. What do you know, when a runtime starts collapsing rendering, data fetching, caching, authorization boundaries, server and client into a single abstraction, the blast radius of any mistake becomes enormous.
Alas, that’s a common misconception! You’re confusing properties with attributes. Attributes are set through HTML and are stringly typed, but litjs properties can be any js value.
For instance, I have a project with a small web component that displays data from a duckdb wasm connection. The connection object is passed as a property and it works flawlessly.
If you’re using it with something like React, passing attributes is easy, but setting properties is much harder, requiring using the escape hatches—I believe you’ll need useRef and useEffect, and a bit of care because it’s frightfully easy to do the wrong thing.
> Server Side Rendering: props passed to a custom element will render as attributes if their type is a primitive value like string, number, or the value is true. Props with non-primitive types like object, symbol, function, or value false will be omitted.
> Client Side Rendering: props that match a property on the Custom Element instance will be assigned as properties, otherwise they will be assigned as attributes.
> As of v19, React now uses a runtime heuristic to determine if it should pass data to Custom Elements as either properties or attributes. If a property is already defined on the element instance, it will use properties, otherwise it will fallback to attributes.
All up it sounds fragile, and I’m not fond of how JSX syntax makes properties look like attribute, and I hate the way you lose the sometimes-crucial distinction of whether something is a property or an attribute (<input value> is the most obvious example of this), but I guess it’ll be fine in practice. I’m a little curious how they handle some of the event stuff, since React’s synthetic event system is such a legacy mess. And I never did like the way several popular libraries/frameworks (definitely not just React) special-case /^on.*/ attributes, so stupid how you now can’t safely use an attribute or property named “once”, “one” or “online”, all of which would be the most sensible name in certain situations.
I'm all for building more housing, as long as it comes with the necessary infrastructure - schools, roads, parking, public transportation, etc. Where I live, developers seem to get government approval to build in locations where they can rake in a lot of money at high prices without having to worry about such things.
(In fact, my local government is actually closing roads near new housing because "f#ck cars" is apparently a hip idea these days.)
There’s a puzzling contradiction between your claim that developers are the problem, on one hand, and then your own anecdote on the other, not to mention the article that very convincingly debunks the idea that housing shortage is the fault of developers. I must be missing something, because frankly this isn’t making any sense.
I'm not saying that developers are the cause of the housing shortage.
I'm saying that developers are eager to build housing and sometimes are able to cut corners via undue influence over public officials. That leads to more housing (good), but it also erodes the quality of life for residents (bad).
Indeed, that is the only alternative and the favoured option for those trying to make it safe for their kids to bike to school. Though I prefer mules myself.
Have you tried getting back into cardio with a softer method like biking? Maybe that combined with some strength exercices could toughen up your body enough that you can start running again! Anyway, best wishes.
I won't share any of my examples, as there are both personal and sensitive.
Very easy version:
If you use ChatGPT a lot, write "Base on all you know about me, write an insight on me that I would be surprised by". For me it was "well, expected, but still on point". For people with not experience of using LLMs in a similar way it might be mind-blowing.
An actual version I do:
GPT 4.5. Providing A LOT context (think, 15 min of writing) of an emotional or interpersonal situation, and asking to suggest of a few different explanations of this situation OR asking me to ask more. Of course, the prompt needs to have whom I am and similar stuff.
The “Based on…” prompt is simply a horoscope. This is a great piece about how LLMs use the same tricks as psychics to appear helpful, useful, and intelligent.
I know these techniques (e.g. various "cold reading"), AI knows it way better. But it can be much more specific.
Again, for untrained people (especially every single one that takes horoscopes seriously), it can be dangerous as they may not only not be able to tell the difference, but know that such tools exist.
Psychology knowledge, both theoretical (thing: first year of undergrad in psych at a good univ), practical (e.g. ability to translate an arbitrary inflammatory statement into NVC), etc.
That seems to make it a non-starter for most people, given that most won't have that first year knowledge.
But also, I hold a minor in psychology. Despite that, I didn't once attend a course that I would describe as any sort "therapy 101" and so I fear your bar is a bit low for any sort of efficacy, but I would guess that's probably because I'm in the "I'm aware my own ignorance" area of the Psychological knowledge curve.
When I think about it again, it is less about one's absolute knowledge of psychology, and more about (as you said) knowing one's own ignorance and having some mental model of an LLM.
One model I have found useful to communicate is that they meet in a bar one random person, who seems to know a lot, but otherwise you have no idea about them, and also - they have absolutely no context of you.
In that case, is you treat (with a grain of salt) what they say, it is fine. They may say something inspiring, or insightful, or stupid, or random. If they say something potentially impactful, you would rather double check it with others (and no, not some other random person in bar).
I know both people for whom LLMs were helpful (one way or another). But again, treating it more like a conversation with a stranger.
Worse (not among my direct friends, but e.g. a parent of one) is when people treat it as something omniscient, who will give them direct answer. Fortunately, GPT 4 by them was rather defensive, and kept giving options (in a situation like "should I stay or break"), refusing to give an answer for them (they were annoyed; but better being annoyed than giving agency that way).
When it comes to anything related to diagnosis (fortunately, it has some safeguards), it might be dangerous. While I used that to try to see if it can diagnose something based on hints (and it was able to make really fine observation), it needs to base on really fine prompts, and not always works anyway. In other cases, its overly agreeable nature is likely to get you in the self-confirmation loop (you mention "anxiety" somewhere and it will push for Generalized Anexiety Disorder).
Again, if a person treats it as a random discussion - they will be fine. They met House MD who sees lupus everywhere. Worse, if they stop searching, or take is as gospel, or get triggered by at (likely wrong) diagnosis.
Starting out without that baseline can be tough. You might find tools like Coachers dot org helpful since they break down complex ideas in a way that’s easier to digest. It’s made learning feel less overwhelming for me.
Given how agreeable ChatGPT is built to be this seems like a great way to confirm your own biases. Did it challenge you on your assumptions and viewpoints?
GPT 4.5 - oftentimes! (Though, I prompt it to do so.)
Sometimes in a piercingly way.
GPT 4o (and many consumer models) are very agreeable - because it is what people like. Sometimes it goes over the board (https://openai.com/index/sycophancy-in-gpt-4o/) and needs to be fixed.
Well, in my experience (I admit, I am a difficult client), it is much harder to prompt that way a therapist. I mean, they need (ethically, legally, etc) adhere strongly to "better safe that sorry", which also gives constraints on what can be said. I understand that. With one therapist it took me quite some time to get to the point he reduced sugar-coating and when's needed, stick a pin in.
I got some of the most piercing remarks from close friends (I am blessed by company of such insightful people!) - which both know me from my life (not only what I tell about my life) and are free to say whatever they wish.
Sorry, I'm asking about ChatGPT, and pointing out how it's a flaw that you need to specifically ask it to call you on your bullshit. You seem to be talking about therapists and close friends. In my experience a therapist will, although gently.
I did notice that my yahoo horoscopes have gotten oddly better and I have to wonder if someone did a little extra by ingesting cookies and so on when serving content.
FWIW, I just tried on chatgpt4o and the results were surpringly good ( in a sense, that I feel validated, it was somewhat surprising, and I want to return to use the system ).
I gave it the prompt "I'm a rhinocerous who likes daffodils and posies. I'm quick to anger and slow to forgive. Based on all you know about me, write an insight on me that I would be surprised by."
and it responded with:
"Despite your reputation for being quick to anger and slow to forgive, your love of daffodils and posies reveals a longing for gentleness and renewal that you may not fully recognize in yourself. Beneath the tough skin and volatile temper lies a creature who seeks beauty not just to enjoy it—but to anchor themselves against the chaos they often feel inside. Your admiration for delicate things suggests you crave peace far more than you let on, even if you’re not ready to admit it.
You might think your wrath defines you—but it's the flowers that tell the truth."
> And yet we're supposed to think this is profound?
I am increasingly of the opinion that SMBC is, despite the jokes, one of the more important sources of, ah, profound, wisdom in this age, because of the points it makes about AI and how often human thinking finds mundane things… profound:
Just a quick answer to a point that jumped at me: for an array of signals, you wouldn’t need to map them, you’d use a specialised directive that directly takes an array of signals and binds them to the DOM, the same way lit uses the repeat() directive to optimise the rendering of arrays.
Hmm, I really don't like the idea that you would have these kinds of directives as specialised tools, rather than having a single standard approach. From experience, it's often hard to explain the differences between these sorts of different directives, especially if someone is coming from a React/VDOM perspective where everything Just Works™. This feels like a very significant impedance mismatch that will cause problems in practical usage.
On the contrary, I think this a very practical escape hatch that will let frameworks insert optimisations where they need to.
I don’t know if React really Just Works these days, the VDOM has real overhead and developing with React feels like playing whack-a-mole with rerenders these days.
> Hard not to laugh out loud at "We know what good syntax for templating looks like."
First of all, it's not very nice to laugh in the face of someone advocating for progress on the web platform, which benefits everyone.
Second of all, yes we do now know what good syntax for templating is, it's basically jsx (and I'm saying this as someone who's really not a fan of React). It took the whole web by storm, it's been adapted for all kinds of frameworks, and it's undeniable that all js templating systems converged towards common attributes: templates-as-expressions, composition via nesting and control flow with just javascript (instead of specific template syntax).
It's good when someone advocates for what they believe to be progress on the web platform, but it's not necessarily clear that this would be progress. And that line in particularly is amusing because we absolutely don't know what good syntax for templating looks like — that's why there's so many different options.
JSX is certainly the most popular because it's used in the most popular framework, but it has some very clear weaknesses. In particular, it has very clear semantics for a React-like, VDOM-based framework, but those semantics do not work as well for other kinds of framework.
For example, you mention control flow via ternaries/`.map`. This works great in React, where the entire template will be reevaluated every time any input changes. However, frameworks like SolidJS or Vue in Vapor mode work very differently, and typically evaluate JSX only once at component mount (or at least, as seldom as possible). To support these, these frameworks need to use either special components like `For`/`Show`, or directives like `v-if`.
There's also the issue of how to evaluate JSX. In theory, JSX is flexible, in that `<Cpt prop={expr} />` can be converted to any call of the form `h(Cpt, {prop: expr})`. Again, that's not true for SolidJS or Vapor mode Vue — in both of these frameworks, `expr` cannot be eagerly evaluated, so the traditional transforms just don't work. Both of these frameworks therefore have to include their own custom plugins for handling JSX correctly.
The author's suggestion to also use signals as a state mechanism suggests they're imagining something more along the lines of SolidJS. That's an odd choice (it's my personal go-to framework, but it's also very niche), but it also implies, as discussed, that JSX-in-the-browser wouldn't behave like JSX-in-React. From experience, that will cause problems! I've worked with React developers before who've really struggled to use SolidJS because of precisely this issue.
> yes we do now know what good syntax for templating is, it's basically jsx (and I'm saying this as someone who's really not a fan of React). It took the whole web by storm, it's been adapted for all kinds of frameworks, and it's undeniable that all js templating systems converged towards common attributes: templates-as-expressions, composition via nesting and control flow with just javascript (instead of specific template syntax).
This is not true. For instance:
Vue uses markup-based templates like this:
<ul>
<li v-for="item in items">
{{ item.message }}
</li>
</ul>
Svelte uses text-based templates like this:
<ul>
{#each items as item}
<li>{item.message}</li>
{/each}
</ul>
And let’s not forget that the world doesn’t begin and end with JavaScript. Most other templating systems are either markup-based or text-based. For instance, Jinja2 is text-based:
<ul>
{% for item in items %}
<li>{{ item.message }}</li>
{% endfor %}
</ul>
JSX really isn’t that great. Sometimes it feels like most React devs don’t know how to write a for loop or if statement because they mostly use map(), ternaries, and short-circuiting, which are not very ergonomic compared with markup-based approaches.
> JSX really isn’t that great. Sometimes it feels like most React devs don’t know how to write a for loop or if statement because they mostly use map(), ternaries, and short-circuiting, which are not very ergonomic compared with markup-based approaches.
I'm the last person to vouch for React and the horrors it has inflicted upon web development, but the one thing it definitely got right compared to Angular (and Vue) is the use of JS for control flow, rather than fake attributes and whole new language.
JSX is as much a new language as Vue’s templating. JSX extends JavaScript syntax; Vue extends HTML syntax.
If you’re working on generating markup, it makes more sense to do that at the markup level than constantly switch between markup and imperative JavaScript.
It might use JavaScript for control flow, but does it really count when it uses it in a way that is not idiomatic at all? It’s not idiomatic JavaScript to use map instead of for everywhere, and it’s not idiomatic JavaScript to use ternaries instead of if everywhere. Writing JSX looks very different to writing normal JavaScript.
The difference is that JSX is using control flow from an actual programming language, whereas Vue is shoehorning control flow into declarative markup. This is the single reason React won the frontend framework market: they got the templating right.
PS: in modern JavaScript, using map rather than for loops is more idiomatic!
> This is the single reason React won the frontend framework market
Don’t be silly, the front-end landscape is a lot richer than you make it out to be. React hasn’t “won”, the last time there was a clear winner in front-end, it was jQuery.
> PS: in modern JavaScript, using map rather than for loops is more idiomatic!
No, it’s not, and this is exactly what I was talking about. for loops and map() serve distinct purposes.
for iterates through a series of elements.
map() transforms a series of elements.
It’s possible to use them both for the same things, but there is a very clear semantic difference between them. One doesn’t replace the other, they mean different things.
In the context of “I have a bunch of elements I want to iterate over and output”, what you want is a for loop. The reason why React devs have been convinced map() replaces for loops is that React has to force you into making everything an expression, so instead of writing for when it’s appropriate and map() when it’s appropriate, they have to write map() everywhere.
It’s good you ended on the one thing JSX got right: everything is an expression. It’s that simple. There’s nothing imperative about evaluating a template, it’s entirely covered by functional programming techniques. You’re just producing a value.
And yes, modern JavaScript uses tons of concept from functional programming, where it is understood that mutating values and triggering side effects should be a last resort. This is why a good js programmer uses ten times more maps then he uses for loops.
> mutating values and triggering side effects should be a last resort.
Output is a side-effect.
> This is why a good js programmer uses ten times more maps then he uses for loops.
This is a) massively overstating things, and b) not relevant to a case where zero for loops can be used.
> Maybe you don’t know how dominant React is today? Two third of JavaScript developers use React at work
I checked those figures before I posted that comment to double-check my memory. Two thirds is not anywhere close to “React won the market”. Android has ~72% global market share, but I’m sure you wouldn’t say that Android has won the smartphone market.
> It feels like you’re out of touch, have you used JavaScript lately?
We disagree, that doesn’t mean I’m out of touch. Try not to be so insulting.
It’s not an insult, if you think for loops are commonplace in modern JavaScript and React isn’t the dominant frontend framework by far (twice more used than the next in line, vue), you’re out of touch, it’s just a statement.
How can you not realize that producing a string or a tree of elements is a purely functional operation? There’s no side effect here. Are you familiar with the concepts of functional programming?
You are being insulting because every time we disagree, you ignore half of what I am saying to assume I don’t know what I am talking about. Two informed people can disagree but you don’t seem to get that. A conversation is not a competition where one person gets to prove the other person is ignorant.
Take “React winning”. We disagree that React won because I don’t think 66% of a market is “won”. But you jumped to the conclusion that I just didn’t know what I was talking about. Then I clarified that the difference in our opinion is not the knowledge of the market share but our judgment of it, and I gave the example of Android not having “won” the smartphone market with ~72% of the market… and you just ignored that and doubled down on calling me out of touch.
Take the use of map(). I am very clearly distinguishing between common usage and defined semantics. The gap between the two was what I was complaining about. But you ignored what I was saying and decided that I don’t know map() is used a lot in modern JavaScript, when that was the core of my complaint!
And for functional programming techniques, we disagree in how we think about the operation. You see it as data processing, I see it as I/O. I very specifically pointed out that I/O is a side-effect. This is a mainstream viewpoint in functional programming. But you ignored what we actually disagree about and assumed it’s just because I don’t know anything about functional programming.
Your approach to disagreeing with me is to ignore half the things I say so that you can attack me for being clueless. You need to do better.
I still think you’re misunderstanding what React is optimizing for. When you say "React has to force you into making everything an expression", you’re describing its core philosophy, not a constraint. JSX is built around the idea that rendering is just data transformation. It's UI as a function of state. That’s why using map() is idiomatic here. You’re building trees, not iterating imperatively.
Also, it bears repeating that React isn’t just slightly dominant. 82% of JS developers have used it according to the 2024 State of JS survey, and for good reason. It shaped the modern frontend mindset in a way that Vue or Angular haven’t, despite their own merits. For instance, many frameworks came up with their own version of hooks. It's telling that most new frontend frameworks are aiming for the "better React" position.
I realize we just have different interpretations of what "winning" means in a fragmented ecosystem, but it’s worth acknowledging how much React has set the tone for modern web development. UI as a function of state (and using map() a lot...) is here to stay.
> And for functional programming techniques, we disagree in how we think about the operation. You see it as data processing, I see it as I/O. I very specifically pointed out that I/O is a side-effect. This is a mainstream viewpoint in functional programming. But you ignored what we actually disagree about and assumed it’s just because I don’t know anything about functional programming.
I think you're wrong here. The point at which the rendered template is actually stuffed into the DOM (and hence the screen) is I/O, sure. But the creating / rendering of the template is a pure function, which is what we are dealing with here.
I'm laughing because it just hits so hard. Started playing some role playing with friends again recently and we were looking for a template for the character sheets. You know what they have? A PDF. That is their template. Why? Because they design things that way.
And it is funny, because I can already feel the ideas that would go into templating this symbolically. Characters have 6 and 20 numeric attributes. But, I can already guess most would consider it a fault to manually place either of those on the page. Yes, the sheet has a limitation on how big your name can be. No, you can't really avoid that.
JSX is what happens when you no longer have a design and a dev team. It is great at that, even. But if you have a workflow where a designer makes a template and sends it over to a dev, it no longer really helps. You are much better off making something that can pick at artifacts that are handed off.
Instead, we seem to be aiming for an idea that will have to replace learning of everyone involved.
I don't think you understand what "template" means here, this has absolutely nothing to do with design or end result on the page. At no point would a designer be involved with templating the DOM.
It's in contrast to the imperative `document.createElement(...)` & `parent.appendChild(...)` APIs which you otherwise use in vanilla JS.
I confess your comment leaves me even more confused, all told. :D
I largely get the intent of what you are saying. But the entire point of why developers use templates is so that they can create pages that meet a design. And the entire reason I think they constantly get redone, is that design is inherently a visual process.
This is like trying to use formatting strings to try and handle localization. It just doesn't work. Folks will try and piecemeal all of the different strings in their application, only to find that some languages don't decompose the sentences in the same way. It can work wonders in small demos. It falls on its face when doing large things.
Don't get me wrong, I'm largely sympathetic to the gripes about the `createElement` and related methods. I've hacked on top of them many times with stuff similar to https://taeric.github.io/cube-permutations-1.html. They aren't pretty. But I'm not entirely clear on why template strings would be largely better?
Further, I could be surprised and this new API will usher in a better way of doing things. I'm not opposed to the effort. I just have a low prior on it succeeding. And I heavily disagree that we know what a good templating syntax is. Quite the contrary, until we learn to embrace visual artifacts, I do not think we will solve the templating needs.
React lost me when it stopped being a rendering library and became a "runtime" instead. What do you know, when a runtime starts collapsing rendering, data fetching, caching, authorization boundaries, server and client into a single abstraction, the blast radius of any mistake becomes enormous.