mistersys

My man must not write JS

title is confusing.

SQL announces: 2023 is finished, on April 13th, 2023.

In my experience in tech, most teams directly access and manipulate production frequently. Bigger companies usually have restrictions on this but in the start up world not so much.

I had a similar experience after switching to DVORAK as a nerdy teenager, however I found by just leaving my smartphone on QWERTY, I'm able to switch and still type 40 - 50wpm with minimal practice on a real keyboard. I'm more like 100wpm on DVORAK.

Practicing both layouts a little may make it possible to keep both modes in your head, but I don't know if a completely different input mode would make this harder.

No need to be pedantic. He's obviously saying that there are better strategies then vDOM with lower overhead.

This is proven by Solid.js which is faster then every VDOM framework, has an API that is functionally the same as react, and doesn't use VDOM.

Solid.js is even faster than inferno, and it doesn't really use a VDOM strategy, uses a strategy much more like svelte. IMO svelte is just poorly implemented from a benchmark perspective.

In reality, most of these benchmarks are not meaningful when talking about real app performance. What's meaningful is how you do global state updates in your app. If you use a react app with react-hook based context providers that unnecessarily update hundreds of components on simple changes, you perf is going to suck. If you use a react app and don't use React.memo anywhere, perf is going to suck. If you use react very carefully and are fully aware of when the vDOM is going to run and use small components that only update when their data actually changes, and ideally avoid running vDOM 60 - 120fps a second for animations, performance is going to be good.

I like Solid.js because it does all this for you by nature of just using the framework. Svelte does some of this for you so for real world apps performance is likely to better than react, but it doesn't do it as well as Solid by nature of it's state management strategy, not by nature of it's DOM update strategy.

The less you update, the faster your app will be. Then the DOM diffing strategy doesn't matter.

Fun idea, but pretty unfun to play. Half the questions are just five, six different words you need to `|` together, and not enough time to even type out that many words.

Feels like the author thinks regex is a useful way to match a bunch of unrelated words in a paragraph. Not really the point of regex.

I also thought this. But then I remembered I had a $700 bike stolen from my hotel when I stayed in SF for 2 days. Checks out.

A successful Web3 (if we want to use the term) project should be unfundable to capitalists. That's what makes this so hard. Teach people how to not be wage slaves, then people won't throw away all their power to the already-wealthy.

It really feels like internet infrastructure has been growing more unstable. More outages, feels like way more bugs happening on my apple products as well.

I believe this is the result of the same thing that causes all the chaos in all human fields, lack of consciousness. We live in a very distracted time, COVID is still one more stressor on top of all the other things we have to manage in the world we've built to be inhospitable to mental health.

There's a shift happening in certain areas, but I think the old guard of tech is due for a revolution of some kind. My two cents, to start we need to stop building things with such low-level tools.

I think the point here is that we've worked ourselves into a corner with web technologies. The web is very reliant on GPU rendering, but when building an app with DOM + CSS, you don't have direct access to all that power. You have to be very careful to construct your application in such a way that it can be efficiently rendered, and actually use that GPU power.

Basically, they're getting rid of the middleman: the web. Think about most modern web frameworks (React, Angular, etc.), they're basically immediate mode GUI frameworks, but we do "virtual diffing" in order to translate our immediate-mode-like code into DOM (a retained mode UI framework), then the web renderers the DOM via immediate-mode-like patterns again. Pretty strange if you think about it.

Our stacks of technology are getting in the way of creating good software. So yeah, it's on old idea, but in light of the state of the art in IDEs and Text Editors today, this is an interesting approach.

Note, this is a problem in the first place because of how good the web is. The web has so much tooling, cross-platform support, and documentation / learning resources that it's being overused in places where it's very inefficient, simply due to momentum and mindshare. When you have a hammer...

Now, one of the biggest reasons for the success of the web is cross-platform support, but it's not just cross-platform support. It's the only write once run anywhere platform, truly. Most other cross-platform frameworks require you to think about the native environment at some point, but it's very rare on the web because of the robust standard library including Media access, Networking and even more rarely used APIs like WebMIDI. Not to mention that web design culture allows you to ignore the ui patterns of the native OS you're targeting, allowing more cross-platform savings.

If we can somehow manage to throw away the DOM + CSS (except, perhaps, for decoration) and replace them with immediate mode frameworks, combine that with WebAPIs for interfacing with hardware, and decouple those from JS (maybe via WebAssembly), then we have a competitor to the web for complex cross-platform software that is actually interesting. Perhaps Zed and their Rust-based GUI framework could help push us in that direction.

Edit:

Another aside, the performance of immediate mode GUI. You could argue that retained mode UI can be made to have better performance than immediate mode, but I think the right combination of caching and framework-level optimizations to allow for partial updates are the solution.

You might say "that's not immediate mode though?", and sure, but what we care about here is fast applications that are easy to build. We've discovered that writing code via declarative patterns has huge benefits over "object-soup", so our goal should be to make those patterns as fast as possible. I think the DOM and retained-mode GUI is a just a result of the Java style of Object Oriented obsession.

The JS Ecosystem + The AWS / Serverless ecosystem is a love story of the likes of Harley Quinn and the Joker.

This week I picked up a gig working on a website for a non-profit organization, the needed some basic changes to a few forms. The reason they had to hire me, a web app developer, the site was built by some agency with Next.js / Jam Stack technologies, Contenful, AWS Lambda, AWS Amplify etc.

This simple website, is one of the most complicated monstrosities I've ever worked with. Every page downloads multiple megabytes of JSON from the Contentful API just to render dead simple pages with text and images. Every time there's a change in contenful, a new build in AWS Amplify is triggered to generate the site to static content... only the React code is so complicated with so many round-trip, nested server requests (n+1+1+1 etc) that the builds fail constantly because the API server (on lambda of course) which serves the Contentful content basically gets DOSed. I had to write logic to retry all app API requests just to get the builds to consistently work so I could work on the website. The code that transforms these megabytes of JSON into webpages must have been written by a mad man.

Also screw AWS for not building proper tools to debug AWS Lambda. Not having to manage servers sounds awesome, so everyone has started using lambda, but the developer experience of having to wait 10 - 15 minutes just to add a console.log line is like pulling out your own finger nails and then scraping them on a chalkboard. Then AWS built the most noisy, difficult to use and hard to navigate log management solution on the planet (CloudWatch), and started sipping their beers.

You can avoid these technologies all you want, but one day you're going to have to work with a project that choose to use them, and you can't control that. I believe library authors and service providers have a responsibility to think about developer experience that's being ignored. Or perhaps, since developers don't always have a choice in the technologies they use, building easy to use developer tools isn't worth it.

This isn't really business logic... unless you're in the business of simply converting data formats.

As a data fetching approach and especially as tooling primitive to eliminate the n+1 ORM problem this is a terrific tool to be aware of.