Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
ember-render-modifiers
Implements did-insert / did-update / will-destroy modifiers for emberjs/rfcs#415
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
next-runtime
The Next.js Runtime allows Next.js to run on Netlify with zero configuration (by netlify)
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
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].
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
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
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.