Congratulations for the release! You are doing an impressive work with bun. I find particulary exciting the built-in sqlite, and I cannot wait to move all my projects to bun. Egoistically speaking (my 2012 mbp doesn't support AVX2 instructions), I hope that now that the project is public, since you are going to get a lot of issue reports about the failure on install, you will find some time to get back to issue#67. Thank you, and keep up the excellent work.
Now I am confused. Did you express the same strong advice against doing this to Dominic when they started working on lexical? In the end draft.js already existed. Why reinvent it? How much should we go back in time to find the point when things started to be so perfect to make everything coming after a worthless reinvention? What I think instead is that some developers have a phobia of writing code, and prefer to glue together various pieces to "get the job done". Others enjoy the process of creating something unique and potentially better, for some connotation of "better" that is not to be disputed. I think that there is nothing bad in doing so.
I know. The APIs offered by browsers for editing text are less than ideal, and require a lot of work to make something robust. That being said, my point stands. If something is not easy it doesn't necessarily mean that is not worth doing. I have my opinions about how text editing should work in my software, and it is my job to design and develop a solution that fullfills my vision. I will take working around the browser APIs every day instead of fighting a library developed to fullfill a different vision, that adds layers of indirection on top of the same problematic browser APIs.
It depends. If the editor is a central part of what your software is doing and you need/want total control, it's well worth it. General purpose libraries are mostly made of bloat when your project just need 20% of all the things they (have to) do. Focusing on that 20% could be a good time investment and yield a better software.
The simulation being massively parallel, it is a perfect fit for a fragment shader. Since the interactions between the particles are mostly local, taking advantage of the fact that the GPU loads a block of neighbouring fragments in the cache to be able to compute the standard derivatives, it should run very well. I will notify you when I find some time to play with it.
Relax. It's a web toy inspired by another web toy. Nothing serious and nothing to be worried about. If you want to change the world for the better, fight against google, twitter, facebook, and their tracking ads networks. Those are the places where a serious amount of CPU cycles are wasted every second producing toxic matter. We need more creative (mis)uses of the web, not less.
Nice work, Jason. I enjoyed a lot a talk [1] at GDC by Petri Purho (Nolla Games and before that Kloonigames) that explains the "Falling Everything Engine" used in their game Noita (that I would love to play on my mac...). Highly recommended if you want to dive deeper into the topic.
He does it "the right way™". Use the platform. Don't use any framework or generic library. Go straight to the point and code what you need, when you need it. Don't minify or bundle anything, and let the people who are learning and courious a straightforward way to connect the dots, without forcing them into a github repository with 90% of the code unrelated to the thing and existing just to glue 1000 pieces written by 10000 people together.
Every essay by Bartosz is so top-notch and a such breath of fresh air! He gives me hope in humanity and I am immensely grateful for what he does.
You have been overly dismissive of Casey's work. HH is a treasure, and if you consider that he explained the how and the why of every single line of code, on stream, without cutting any corner, your consideration about the time spent become meaningless. There are people interested in copy-pasting and glueing together pre-baked parts to ship something, and there are people interested in developing a deep understanding of how things work, to be able to break and reassemble new toys with complete freedom. There are people that value the product and people that value the process. Casey's work is targeted at the second group, and I thank him immensely for what he does, even if some of his rants are pretty ignorant (usually when talking about things he knows nothing about). Take the good parts. There are many.
I write a lot of code on the iPad (more than 40h/week, both webdev and native, since at least 4 years) and I like it better than using my (aging) laptop or a desktop computer. It's incredibly smooth and forces me to do mostly one thing at a time. I find it a better match with how my brain works. That being said, you cannot do everything on it, but that is part the point.
The best explanation is probably the one by Casey Muratori (https://caseymuratori.com/blog_0001). He devised the technique and conied the term in 2002.
You can find it under System Preferences > Keyboard > Shortcuts, in the Keyboard section. The shortcut name is "Move focus to next window". It will automatically cycle the windows in reverse order adding shift to the shortcut.
For MacOS this is not true. You will get Safari stable decoupled from the operating system going back two versions (Catalina and Big Sur). What you cannot run is Safari Technology Preview, that is available only for the current OS version.