proposal-shadowrealm
vrite
proposal-shadowrealm | vrite | |
---|---|---|
19 | 23 | |
1,376 | 1,487 | |
1.2% | 2.9% | |
6.0 | 9.2 | |
13 days ago | 5 days ago | |
HTML | TypeScript | |
- | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
proposal-shadowrealm
-
Updates from the 98th TC39 meeting
ShadowRealm: ECMAScript Proposal, specs, and reference implementation for Realms [Stage 3 -> 2].
-
Should you use jest as a testing library?
You can't out of the box. There is an open issue on the Node.js repositoryto let the node:vm module to use the vm's context, but it is still open. It seems that the Node.js core team is interested in fixing this problem by implementing the new ShadowRealm spec, and I think we will make some progress during 2023.
-
Building an Extension System on the Web
ShadowRealms — a successor of the Realms proposals, this API is intended for use cases exactly like plugins or extension systems, providing an option for creating distinct global environments to run the code in. While not entirely secure on its own, this API could provide a strong foundation to build actual extension systems on the Web. That said, 4 years later, the TC39 proposal is currently only at stage 3, not implemented by any browser;
-
Vitest vs Jest benchmarks on a 5 year old real work SPA
With --no-isolate it was 2.8x faster than vitest and 1.7x faster than Jest, but 19 tests failed (see table above). Some people report issues with watch mode when using --no-isolate. So I decided to not pursue it any further. Once the vm module that Vitest relies on supports ESM, or when the amazingly named Shadow Realms are added to JavaScript, we will likely get this performance boost for free without the downsides.
-
Improving Vitest Performance
If ShadowRealms are ever added to EcmaScript (and implemented into V8/Node) they'll allow for a different approach to isolating code that would be faster without the downsides of sharing global.
- Virtualization is not an important enough use case for the web platform to tradeoff ergonomics and possible confusion for web devs, who by and large […] do not understand the separation between the specs. More to the point, they really shouldn't need to.
-
Is there an npm package for perchance?
Eventually I will get around to creating a "proper" package by just grabbing all the JS that is loaded by the code in the iframe, and bundling it up. We really need the ShadowRealm proposal to go through because the perchance engine messes with a lot of JS internals, so it would mess up the rest of your app. Could do it in a WebWorker, but then everything would have to be async.
-
Show HN: Run unsafe user generated JavaScript in the browser
The upcoming JavaScript Shadow Realms proposal looks like it solves a similar problem: https://github.com/tc39/proposal-shadowrealm/blob/main/expla...
- Named Element IDs Can Be Referenced as JavaScript Globals
-
Running user code in the browser (for a leetcode clone)
Browser-based JavaScript doesn't yet have a way to isolate code fully in this manner though there is a new JavaScript feature on the way that would provide this capability. Its called ShadowRealm and would basically give you a new global context to execute code that's completely separate from your main document code.
vrite
-
I Published This with Drag and Drop using Vrite
These reasons (and many others) are why I decided to create Vrite - an open-source developer content platform.
-
WYSIWYG for MDX?! Introducing Vrite's Hybrid Editor
Vrite is an open-source developer content platform, featuring extensible editing experience, content management tools, and powerful APIs. It’s intended as an all-in-one, collaborative solution for product documentation, technical blogs, and knowledge bases.
-
Vrite v0.2.0 - open-source, collaborative developer content platform. Alternative to likes of GitBook, Confluence, Notion, etc. Now with self-hosting support!
So, I've been building Vrite as an open-source project for a while now, and I'm happy to finally share it here - with v0.2.0 now having official self-hosting support.
- Show HN: Vrite – open-source, collaborative developer content platform
-
🤖 AI Search and Q&A for Your Dev.to Content with Vrite
Let’s start by getting into Vrite. You can use the hosted version (free while Vrite is in Beta) or self-host Vrite from the source code (with better self-hosting support coming soon)
-
🔥✍️ Notion-like Experience for Your GitHub Content
You can use Vrite via the hosted version (that’s free while in Beta) or self-host it from the open-source repo (though good support for self-hosting is still in the works).
-
Vrite Editor: Open-Source WYSIWYG Markdown Editor
Since Vrite (and Vrite Editor for that matter) is currently in Public Beta, new features and improvements are in active development. The best way to try it out right now is through the hosted version at app.vrite.io (free while in Beta) with better self-hosting support in the works.
-
I’ve built an open-source, collaborative, WYSIWYG Markdown editor
The editor itself is a standalone app, extracted from the larger Vrite CMS project (https://github.com/vriteio/vrite) which you can also test out (only with sign-in) here: https://app.vrite.io/
-
Show HN: I've built open-source, collaborative, WYSIWYG Markdown editor
The main output is JSON ProseMirror format. Other formats are processed from this JSON using Transformers and Vrite SDK: https://github.com/vriteio/vrite/tree/main/packages/sdk/java...
In the GFM transformer I try to follow GitHub Flavored Markdown spec, which technically doesn't support embeds. Since I didn't find any "common" syntax to use for the embeds, I just left them out. They're still there in JSON and HTML outputs.
That's one of the drawbacks of MD. That said, I plan to add an option like Markdoc, which has clearly defined spec for implementing custom blocks like embeds.
That said, for now, if you sign up for the full Vrite CMS, you can create a custom Transformer and process the output so that embeds are included in your desired format. That's what I'm doing for auto-publishing extensions for platforms like Dev.to and Hashnode. I don't know what your use-case is, but I thought it's worth noting.
-
How I put ChatGPT into a WYSIWYG editor
The process basically came down to figuring out the position and size of the block node, given a selection of an entire top-level node or just its child node (source code):
What are some alternatives?
wtfjs - 🤪 A list of funny and tricky JavaScript examples
openai-node - The official Node.js / Typescript library for the OpenAI API
Pentive - Collaborative Spaced Repetition
markdoc - A powerful, flexible, Markdown-based authoring framework.
vm2-process - Execute unsafe javascript code in a sandbox
marktext - 📝A simple and elegant markdown editor, available for Linux, macOS and Windows.
caja - Caja is a tool for safely embedding third party HTML, CSS and JavaScript in your website.
solid-primitives - A library of high-quality primitives that extend SolidJS reactivity.
LavaMoat - tools for sandboxing your dependency graph
solid-docs - Cumulative documentation for SolidJS and related packages.
rua - Build tool for Arch Linux providing control, review and jailed build options
stackedit - In-browser Markdown editor