Lexical is now open-source! 🎉
None of this would have been possible if it wasn't for the awesome team that work on Lexical full-time! I hope folks get a chance to play around with what we've spent the last 18 months building.
I’ve been working on a new React-like framework in my spare time.
It’s fully compiler driven, there’s no virtual DOM, or component re-rendering. There are signals, but they’re never exposed to the developer and they’re also fully compiled to avoid any runtime lookups.
And…
We've been building Outline – an extensible text editor library that does things differently. If you use or , you've likely already used it.
We're expecting to open source it early 2022.
Website coming soon:
I recently spent 2 days on a hackathon project to see if it was possible to render React to HTML at build time with Prepack. I focused on getting our Hacker News benchmark, written in React, working and passing tests. The results were very interesting!
I personally think that 2018 will be the year that JavaScript frameworks start to become JavaScript compilers.
Here's a sneak peak at what we've been working on in collaboration with the Prepack team:
For those that don’t already know, I left the React Core team at Meta 2 years ago. Why? I wanted to work on a different problem that is essential to the web — rich text editing/authoring. Specifically around web’s contentEditable.
The problem here isn’t the editor, it’s the browsers’ interpretation of the Selection API around contentEditable. It’s almost impossible to build a decent text editor around contentEditable today - there are so many edge cases battling against you.
It's a shame that JavaScript getters/setters on object literals (inside a closure) perform so poorly compared to getters/setters on classes. The difference in all JS VMs is huge – as much as 80x difference in some cases.
I’m excited to be sharing what I’ll be doing next!
Early next year, I will be joining
@TechAtBloomberg
The Bloomberg Terminal is based on Chromium so the UI is nearly all DOM rendering. I’ll be working on the JS infra to make the Terminal blazing fast.
The React Core team is joining the Facebook employee walkout in solidarity with the Black community.
Facebookʼs recent decision to not act on posts that incite violence ignores other options to keep our community safe. We implore the Facebook leadership to
#TakeAction
.
I think Signals are essential for front-end web, and if done right, they solve so many problems.
I'm looking forward to working with
@EisenbergEffect
,
@littledan
,
@RyanCarniato
,
@BenLesh
and a few others to try and make this primitive a reality.
It'e early days though.
It’s been epic working on Svelte 5 for the last 9 months. It’s not far from a RC release too!
So many ideas, sparks of excitement, eureka moments and complicated and frustrating sessions battling edge cases.
It’s funny because after working on the React core team I told myself…
We're looking for contributors for Prepack – . Prepack is a JS ahead-of-time compiler that aims to optimize entire JavaScript applications. If you're interest in helping out – please reach out. We really believe we're on to something here.
Svelte is maturing. Svelte 5 will have native support for TypeScript in templates (you still need to do lang="ts" on the script tag).
Plus you don't need to use `<slot>` anymore with Svelte 5, which overcomes the difficulties with slot props, and the indirection around what…
After reading through the source of SolidJS and understanding some of the design constraints, I'm really excited about its future. You can see lots of inspiration taken from other libraries, and lots of innovation too.
I recommend checking it out too:
Today, I am sharing the news that after 6 years, I will be leaving Meta early next year.
It’s been an awesome journey and I’ve had the privilege of being able to work on so many great projects, and learn from so many talented people.
I often use JavaScript Maps and Sets and often have to enumerate over them. I benchmarked this about a year ago, and found extracting an array via Array.from and then looping over was fastest. Now it turns out for…of on the Map/Set is fastest. How things change.
A few days ago I was was uninvited to a React event because the organisers thought I was "kicked" off the React Core team.
I asked why they thought that was the case and they assumed I left the team because I hadn't done anything in my time on the team.
This is what we've been working on for the last few months. It's a new event system for React that is a complete departure from how events on handled today in React, or the DOM for that matter. The aim is to have a unified, declarative event system that works cross platform.
I’m so excited by the work
@trueadm
and
@necolas
are doing on React Flare (experimental), especially this PR:
It’s going to make event handling in React drastically, ridiculously, blazingly better
I work on a team that has been working on a new text editor library that we hope to open source next year.
Being able to launch it on FB/IG/WP/WA and get signal has been a key indicator if we’re doing it right. It’s hard building a great text editor UX/DX around contenteditable.
I think one of the strangest things about working on Svelte compared to React — so many people understand that React is backed by a team, but somehow Svelte is not.
Let me assure you, it’s no different here. Svelte is backed by a team. Svelte might be
@Rich_Harris
’s baby, but…
I got asked today an interesting question. If I were to make Inferno today, what would I have done differently.
- I wouldn't use React's API
- I would make it formally use an ahead-of-time compiler design
- Wouldn't abstract over HTML and instead build around abstractions
I've been working on the Svelte core team for the last month and it's been a blast. We've had so many great discussions about the future of Svelte. There is some very exciting and innovative stuff planned. :)
This tweet is almost 5 years old, but I still love the idea today.
Aside from that, I still think compilers are awesome. With love and care, they're a genuine way forward towards alienating a whole category of complex UI issues that modern frameworks experience today.
@threepointone
@youyuxi
for anyone following along —my thinking has evolved in the last hour. I don't think hooks are the right direction for Svelte. Instead I want to do something more like this, which we can do because WE'RE A COMPILER, MOFOS
One thing I've always wished JSX had, was the ability to define intermediate statements in a special JSX block – a bit like how you do PHP in <?php … ?>.
Having something like a `<? … />` JSX element would improve control flow and improve readability IMO.
Since working on Svelte, I always get asked if I really prefer jsdoc over TypeScript.
No, I don’t.
Furthermore, if we had type definitions in the language (there’s a proposal for it) then Svelte could go back to using types instead of jsdoc. We just don’t want or need a build…
I'm kind of getting fed up with frameworks prioritizing performance, data-fetching and server-side rendering capabilities over basic UX necessities. It should be a high-priority that frameworks focus on making the web accessible and preventing, if not blocking, bad practices.
There’s been a lot of talk about meta-framework performance. Much of the discussion around frameworks tends to be for traditional websites.
There’s a whole other category of apps in the finance/collaborative/real-time/messaging space that demand low-overhead runtime perf.
I've been asked a bunch in DMs lately what I've been working on since leaving the React team last year. I can't really say too much about it right now, other than I'm working on an awesome JavaScript text editor library. :)
I came up with a bunch of ideas that eventually led to
@lexicaljs
. I’m super proud of the project and the core team behind it. I often get told that it’s the “React of rich text editors”.
The best part is that Lexical is framework agnostic, so there’s little excuse to try it.
My goal was to see if it was possible to eliminate React completely from the bundle and generate a simple JS file with the minimal logic necessary to render the HTML. Even though I made zero attempt on optimizing the output, the results were great:
It was great catching up with
@Rich_Harris
again today. For those who don’t know, Rich got me properly interested in JavaScript with his work with Ractive. What a ride it’s been since those days!
I had lots of great disucssions yesterday with
@sebmarkbage
,
@necolas
and
@dan_abramov
. We went down so many rabbit holes and considered so many problem spaces.
It ultimately led to a redesign of the prospoal that I've been working on. Here's the PR:
I often see and hear people talk about how React's most important feature is its "virtual DOM". It really isn't.
The "virtual DOM" is a concept and an internal React implementation detail. You should be able to create UIs with React without ever needing to know about it.
@mark_struck
I guess that's a good question if you've never heard of me. I worked on flat bundles for React 16, Prepack (AOT compiler project that led to hooks), came up with the naming of hooks, re-wrote the event system for React 17, working experimental a11y APIs and many more things.
I was told that I was the one to blame for the spread of the phrase "blazing fast". So many JS libraries are using it now and apparently I started it with Inferno. Well, Inferno means "a large fire that is dangerously out of control" so at least the term "blazing" was accurate.
I envisage a future where creating lifecycles and state in React wasn't coupled to class components. What if they were their own primitive within React? Here are some ideas I've been throwing around in a gist, what does everyone think?
It's great to see
@fbOpenSource
sponsoring
@RollupJS
. Thank you to everyone who's been behind Rollup and contributed to the project. Rollup is such a great tool and has really helped improve us improve React's build process.
You don’t need to worry about memoizing everything and effects and useMemo don’t require dependencies. Hooks can be conditional. You can await async data within your components directly (the compiler is smart).
And…
There are two DOM APIs that I'd love to exist today. Their usage would be primarily by frameworks and libraries, resulting in less code and fewer bugs and more consistent performance:
- reconcileChildNodes(arrOfNodes)
- createDocumentFragment({persistent: true});
If only…
I still find it crazy that after so many years, we’re still having to deal with the first request to a website returning HTML. What if it could return a highly optimized version that represented the same package but was smaller in size and a tiny zero parse cost?
It's kind of crazy, after the latest version of Chrome, Inferno is now much faster in the JS framework benchmark.
Nothing has really changed in years, yet it still comes in faster than almost anything else out there. Oh, it still has a virtual DOM too.
Another question I've been asked lately - what have I been working on?
I'm working on a rewrite of React's event system. We're calling it the "modern event system" internally. The major change is that we don't listen to events on the "document" but rather, the React Root element
People often find it strange that I never use `console.log` to debug things when I'm coding in JavaScript.
Personally, using `debugger` statements and breakpoints work better for my mental mindset. I often want to inspect the call-stack, or check various values at their point in…
During my parental leave at Meta, I thought it would be cool to hack on a new JS frontend framework with my partner
@woodfsarah
. You can imagine it as a mix of some of the best ideas and concepts from React + Solid + Prepack + Inferno + Lexical. It's still early days though…
You can still use idiomatic JS, like if statements, early returns, , destructure props etc.
There are however some constraints. You can’t use “let” or mutate objects in the component body - as this makes it far harder to compile and might be a side effect.
I honestly think we’ll soon (in the next year) see something that seriously disrupts React’s hold. The amount of variables has always been a catalyst for big change. I personally think healthy competition is be beneficial to the ecosystem. Exciting times.
I decided to share the React Compiler experiment that I was working on a few years ago in my spare time:
I didn't have time to continue working on the project, but there are a bunch of ideas in the project that other folks might find useful.
As I alluded to on my stream with
@RyanCarniato
, one of the great things about Svelte 5's runes is that the compiler can determine whether or not something even needs to be backed by a signal.
Signals are great for updates, but can have a non-trivial cost on page load when the…
as you wish — here's a SvelteKit version:
mostly the same but with a couple of small tweaks. more info at
built this in about 45m, and i'm about to hit the back bowls at vail so if i missed anything will fix later ⛷️
Another important implementation detail: Outline's core library doesn't have any dependencies. This means it can be used with any framework. However, we will provide React bindings with Outline when we go open source, as these bindings are already used and battle-tested at Meta.
To be clear. The limitations are only constraints for now. Limiting lets etc can be loosened, it just takes more time to make this sort of problem space work. It’s far easier to start constrained than the other way around.
So I got fed up with my prediction and just decided to work on Svelte so that everyone else would be encouraged to catch up.
Joking aside, I think 2024 will be the year you see what’s possible with compilers. With React Forget on the horizon, I think we’ll start to see more…
This tweet didn’t scale as well as it should have.
I do however think this year will be that year. JavaScript frameworks will start to become “proper” compilers, except some exceptions like Svelte, which already are.
@ryanflorence
You should see what I’m cooking up. It’s a game changer in terms of perf, bundle size and DX. Like a mix of React, Solid and Svelte. Compiled with something that goes much further than any framework compiler before.
I really like the idea of "signals" being an implementation detail of a framework.
If the core philosophy is to enable reactivity for a UI, then the implementation details aren't really that important. Furthermore, it allows for changes to those details without breaking changes.
All of this was made possible by the progress we've made on Prepack and how much it's capable of handling now. We still have a lot of work to go and this experiment in Prepack is by no means usable (it's full of TODOs and hasn't been tested on anything other than this benchmark!)
I’m so happy for
@threepointone
and the journey he’s been on so far. He’s one of nicest and smartest people I know too, not to mention I’m so excited about what’s to come in the future with
@partykit_io
. 🔥💰
For those wondering what I mean by a primitive, I mean it's part of the ECMAScript language. It would be great if a whole class of issues were solved at platform time, whilst enabling frameworks to drop several KB in JS to make it happen.
What was interesting about the responses to this tweet is that people got hung up with signals and the fact I opted to use React’s APIs.
Signals and React aren’t even that important really. It’s the compiler that is. Imagine a UI compiler that leverages AI to self-improve…
I’ve been working on a new React-like framework in my spare time.
It’s fully compiler driven, there’s no virtual DOM, or component re-rendering. There are signals, but they’re never exposed to the developer and they’re also fully compiled to avoid any runtime lookups.
And…
I've been thinking about how state and lifecycle events might be handled in React. What if they weren't coupled to the component – maybe we've been getting that bit wrong. What if they were independent and declarative, for example a state reducer:
I know it's highly unlikely, but I wish there was a reactive form of binding in JavaScript as a primitive. Like:
let bound x = 1
let bound y = x + 1;
x = 2:
console.log(y)
This would open up so many opportunities IMO.
This tweet didn’t scale as well as it should have.
I do however think this year will be that year. JavaScript frameworks will start to become “proper” compilers, except some exceptions like Svelte, which already are.
I personally think that 2018 will be the year that JavaScript frameworks start to become JavaScript compilers.
Here's a sneak peak at what we've been working on in collaboration with the Prepack team:
I can't stress this enough.
I've had the fortune of working with some of the best designers and engineers I've met, and I've always had situations where I've had to remind them of their decisions and the implications it has on accessibility.
Accessibility should be de-facto.
@klappy
I think it's really interesting that, as an industry, we're happy to ship hacky shit as long as it works for people that have no accessibility issues.
TBH is a terrible perception. Ever user matters. Make your UI work for everyone, don't cut corners with hacks and show empathy.
I don’t think today’s meta framework address this space enough. A lot of effort has been put into making initial interaction fast, but these classes of app demand different requirements.
The irony is they’re also tend to come from clients with the most capital to invest.
Is there a DOM node that has no impact on visual/layout that can be used as a form of marker? Sort of like a comment node, but one that you can lookup via a query selector?
I also tried using an element with display: contents, but that doesn't seem to work well.