-
I built this to avoid this exact problem: https://github.com/cheatcode/joystick.
No desire to be acquired (open to investment but that's it), just build a business around accompanying features/services.
Goal is fast, simple, and friendly regardless of your skillset. No lock-in as the entire thing is a thin abstraction over Node.js and components are built using plain HTML, CSS, and JS (no special languages or syntax).
Feel free to email me if you or your team have questions: [email protected].
-
InfluxDB
Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.
-
Yeah, rewriting it with Electron + Svelte + a Rust backend for the heavy lifting.
I looked at alternatives to Electron because I wanted to avoid the bloat, but nothing felt like the right fit. Tauri (https://tauri.studio/) is the most exciting, but I couldn't find a good way to get raw video frames into the UI without a bunch of expensive copies or serialization. I also looked at native toolkits like Qt (I've worked with it in the past) but I didn't love the idea of building lots of custom UI components without the benefit of HTML + CSS. So for now it's Rust + Electron, and I'm paying extra attention to performance.
-
SvelteKit has an out-of-the-box adapter for Cloudflare workers: https://github.com/sveltejs/kit/tree/master/packages/adapter...
-
The TS ergonomics still have a long way to go, imo. Typing components is a little bizarre -https://github.com/sveltejs/language-tools/issues/442
-
ember-render-modifiers
Implements did-insert / did-update / will-destroy modifiers for emberjs/rfcs#415
What I like about Ember is that it gives a lot of rigid structure that, at least at one point, made it comparatively easy to work on multiple Ember based projects and be productive sooner.
As you've pointed out, a problem with that project is that there's a ton of intimate knowledge for how things work under the hood or why things are the way they are. They also seem to oscillate between opting for simplicity and opting for complexity and magic.
One example would be the latest version of Ember which doesn't even ship with `@ember/render-modifiers` by default despite how everyone will end up installing it anyway because it's necessary; they were talking about providing an alternative based on the actor model, despite modifiers being far easier to understand, somehow they are still wrong:
> Either way, we recommend using these modifiers with caution. They are very useful for quickly bridging the gap between classic components and Glimmer components, but they are still generally an anti-pattern.
https://github.com/emberjs/ember-render-modifiers
Why on earth did they reinvent components and ship them without providing the supposedly correct way of interacting with their lifecycle? You actually have to install a separate add-on to develop a production-ready app with Ember, which completely flies in the face of the idea that you can run `ember new` and have pretty much everything you need.
Strangely (an thankfully), the RFC for the needlessly complicated alternative for lifecycle interaction is effectively stalled:
https://github.com/emberjs/rfcs/pull/567
By their own language, the only official way to interact with component/element lifecycle is an antipattern.
/rant
-
What I like about Ember is that it gives a lot of rigid structure that, at least at one point, made it comparatively easy to work on multiple Ember based projects and be productive sooner.
As you've pointed out, a problem with that project is that there's a ton of intimate knowledge for how things work under the hood or why things are the way they are. They also seem to oscillate between opting for simplicity and opting for complexity and magic.
One example would be the latest version of Ember which doesn't even ship with `@ember/render-modifiers` by default despite how everyone will end up installing it anyway because it's necessary; they were talking about providing an alternative based on the actor model, despite modifiers being far easier to understand, somehow they are still wrong:
> Either way, we recommend using these modifiers with caution. They are very useful for quickly bridging the gap between classic components and Glimmer components, but they are still generally an anti-pattern.
https://github.com/emberjs/ember-render-modifiers
Why on earth did they reinvent components and ship them without providing the supposedly correct way of interacting with their lifecycle? You actually have to install a separate add-on to develop a production-ready app with Ember, which completely flies in the face of the idea that you can run `ember new` and have pretty much everything you need.
Strangely (an thankfully), the RFC for the needlessly complicated alternative for lifecycle interaction is effectively stalled:
https://github.com/emberjs/rfcs/pull/567
By their own language, the only official way to interact with component/element lifecycle is an antipattern.
/rant
-
Do you have experience with denoflare? I really would like to try it, but I can't even get the basic `hello-worker` sample working, see https://github.com/skymethod/denoflare/issues/2
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
next-runtime
The Next.js Runtime allows Next.js to run on Netlify with zero configuration (by netlify)
-
It's actually a fairly small change, the spec is here:
https://github.com/facebook/jsx
-
The React team had explorations of a compiler for React, I believe -
https://github.com/facebook/react/issues/9223
-
https://github.com/facebook/react/issues/7324
I also think this is why facebook had been investing in `prepack` - https://github.com/facebook/prepack
-
Subjective indeed. If the goal is to leverage the full expressiveness of JavaScript, you could just alias React.createElement to something like `h`. Or use something like https://github.com/caderek/react-plain
-
I agree, but it can be made easier by exposing named functions that help like useUnmount
https://github.com/streamich/react-use/blob/master/src/useUn...
-
Not clear from your wording, but Svelte Native incidentally does exist:
https://github.com/halfnelson/svelte-native
It's a Svelte renderer for NativeScript (a framework targeting iOS and Android), rather than being a port of React Native to Svelte.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
