Ryan Carniato

That's like saying a paper weight can be used as a hammer.

Fair enough. I'm obviously biased. I've been preparing for this inevitable flattening. I don't know what the next higher-level abstraction looks like right now, nor do I care to. I like vinext's existence as I think it will likely give an indicator where the value is (or isn't).

Yeah I shouldn't be using perception of reactions. I agree about React. React being the defacto choice or not doesn't really change the importance of the language being there, just opens the door to other languages. Part of that being due to shaking up what lies on top.

True but RSCs require almost all those pieces to complete the abstraction. So if that is the abstraction you want to build on it makes sense that React owns it and not say Next.js.

I mean libraries still have a place too.. the thing that doesn't as much is the glue. Core library encodes more behavior.. extension libraries fill the gaps.. orchestrator less important of a role because of growth on both sides.

Looking at how people responded to Vinext, there is nothing contentious about dropping Next. But swapping out React? Not even a consideration. I mean you pretty much said it first. JS Frameworks are languages. Svelte's direction doubles down on that.

So my expectation here is that this back porting happens until we hit a point that the remaining infrastructure, best practices are so encodable that while I doubt we drop our higher level harness it becomes equally reasonable that AI comes and circumvents it.

It's inevitable many of these pieces become core. Part of the language so to speak. I think all framework authors intrinsically feel it. Look at the work we've all been doing the last 5 years. It's like we knew the direction but didn't know exactly what the catalyst for change would be.

And I honestly think we've had varied success there. Metaframeworks mostly exist as a stopgap to cover our lack of knowledge of how to best integrate/redefine the boundaries in the core libraries. With just enough opinions sprinkled in to keep use easy.

I agree about structure being important. People see abstractions disappearing. I see them flattening. And potentially new ones being introduced once we see the shape. I will argue that in frontend a lot of the work the last 8 years has been around reducing perceived complexity.

I think AI wants DSLs they want encoded behavior they can easily express intent with. They will write/grab all the pieces, amalgamate all the parts to fit the prescribed opinions of the day. So library in the React is a library sense, not the isOdd on npm sense.

I mean I already know because of the disagreements/differences between frameworks some of these things shouldn't be standardized. If we can't reach alignment even there what hope do we have. I really don't like having to work against the underlying platform because of assumptions made.

This isn't that interesting to browsers because they can special case for the DOM to streamline. And why would JS care about having a markup template syntax. Tagged Template Literals already allow it. The problem is 3rd party tooling won't standardize around a non-standard.

Well the conversation started because I was trying to get types in Tagged Template Literals that resembled markup. The characteristics I'd want in that solution are similar to JSX where there is a set syntax with no semantic meaning. Ie.. not DOM specific. Ie Runtime swappable.

Yes. Until it doesn't. Software's lack of physicality has let it get by. You'd never expect a local bridge to be constructed by a few neighbours without any oversight, because they had a need. Who is responsible if it collapses? Software should be no different. Can't hide behind AI indefinitely.

I mean so do people. Once you aren't responsible for building what you design. The consequence is you get better at producing clearer specs. I'm not saying AI doesn't assist in that too. I'm just saying that is the artifact.

We should become stricter here. Look at all the security issues of late.

To frame it another way:

Code was never the goal.
Code isn't the hammer either.
Code is the nail/screw. It's part of the output, it holds it together and defines its shape. It's a functional material, building block.

How often does a mechanical engineer pick up a welder? Or electicral fabricate the production chip? They might make a prototype but they aren't responsible often for manufacturing. They write specs, create designs, test prototypes. Code was never the goal. It's the materials.

The profession isn't going anywhere. But if your current job is the equivalent to basket weaving you might need to re-examine where you stand.

And it changes the skills we value and how we measure success.

It shines a light on long held misalignments. Success by LoCs is like if operations in the industrial revolution measured by the size of their electricity bills.

I think AI paints a pretty clear picture. Software Engineering is finally going to resemble other Engineering disciplines. The skills and expertise needed fall more in line. That is a huge switch. It changes the way we teach, it changes the way we hire.

We can take an idea all the way to a product, distributing to users, without leaving our desk. And while when scaling this up, we can benefit from specialization, we haven't always needed it.

The next few years are going to be interesting. Despite the popular belief that the world is going to slop. Things like this tend to do the opposite.

We've been blessed working in software to have one of the greatest professions.

The few opportunities I'd consider are probably around CSS. Like scoping etc... Animation. And more complex DOM movement/multi-element references. Interface level stuff.. managing Navigation/URL, external devices.

Very little. Look for opportunities for missing building blocks and improving native built-ins. Most of the gaps in the platform probably gaps in language level primitives not necessarily the DOM.

I'd also push for honest conversions with supports like Lit to clarify they are a 3rd party framework. And that even if they are very helpful guiding the path the dream of completely disappearing was unlikely. Warn them that a framework doesn't belong in the browser.

Recognize in other cases that 3rd party solutions are completely necessary and the usage of these CEs are for that specific role (custom elements). I wonder if I could make that obvious from API design not cause confusion. I'd also push hard on rebranding away from Web Components.

Now I get that is what made elements attractive.. They weren't a new abstraction. Something we intrinsically owned. The problem is this would also have to curb my ambition. DOM only exists in the browser, so that is where the limits exist. Ie.. CSR only and everything that comes with that.

Signals arguably are fine as a JS spec, universal primitive. But as interop point on the browser too many variables. If I had a vested interest here, I'd focus on mechanical shortcomings and not on creating new abstractions. I'd recognize that it was a bit late to try and do that.

If I respresented the browser I would have a hard time caring about platforms that weren't me. So I get where they where they are coming from. Would I ship Signals and Templating... I hope not.