gpuweb VS slate

People keep spreading this incredibly misleading statement, and yours is even more misleading (suggesting Apple opposed a 'GPU WASM')

By all accounts, Apple's /only/ stance was that if WebGPU used SPIR-V it would be a non-starter for them, due to ongoing legal issues between Apple and Khronos.

Apple actually proposed WebHLSL in collaboration with Microsoft, to have HLSL be the standard.

Mozilla employee's stance[0] was that SPIRV was too low level, did not fit with the goals of WebGPU portability and security, and expressed concern that Khronos may add functionality to SPIRV they cannot support in WebGPU like raytracing instructions .. 'So we'd always be on the verge of forking SPIR-V in some way.'

It was also noted by many people that even if a bytecode format was used, it would still have to be translated to the target (HLSL/DXIL, MSL, etc.) in almost the same way a text format would.

Nobody proposed a 'GPU WASM equivalent' or an alternative bytecode format.

The hard truth is that shader compilation is a fucking nightmare, people do not realize how bad it is across the different native APIs. SPIR-V is good, but it doesn't solve that - and presents other challenges if you are a web browser API. Vulkan and SPIRV are not the golden goose many make them out to be.

[0] https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...

Yes it is still a bit new. WebGPU is not finished and is still being worked on: https://webgpu.io/

WebGPU currently doesn't support the "bindless" resource access model (see: https://github.com/gpuweb/gpuweb/issues/380).

The "max number of sampled texture per shader stage" is a runtime device limit, and the minimal value for that seems to be 16. So texture atlasses are still a thing in WebGPU.

There's even an implementation under discussion to have the dp4a instruction added to WebGPU (https://github.com/gpuweb/gpuweb/issues/2677)

- it creates a layout based on rows and cells, so it support multi-column layout - each cell can contain a different "cell-plugin", - richt-text editor based on https://github.com/ianstormtaylor/slate is built in and comes with its own plugin system. It can do weight, italic, block-types, alignment and lists and can be extended as you want (even with elements storing data and interactive components) - you can create custom cell plugins based on a schema (or custom control ui) and a component that should be rendered - it stores an object tree that represent it, not html. It therefore can contain any react component, which is great if you want to allow your editors to add interactive components or components that you already built as part of the app - i carefully optimized for SSR and bundle size, so no editor ui is rendered nor loaded. editor ui is only loaded on the client if you disable readOnly. (lazy loading) - it mainly tested with nextjs, since i used it for content-heavy pages. - its not yet tested with react-server components, but it should actually work in read-only mode

Finally there's Slate and Lexical which are super powerful in terms of customizability and extensibility. They're great options for when the editing experience plays a major role in the product.

Slate, as per its documentation, is a completely customizable framework for building rich text editors. Therefore, it doesn't offer a feature-rich text editor but instead provides tools to build one. Let's create a component called Slate and see what the Slate editor looks like.

Link to Repo

Word of warning about Slate: I love the API and the design goals, but it appears to suffer from some fundamental issues. We were experiencing issues similar to this one and a team of multiple 10+ year experienced frontend devs couildn't figure out what was going on. I had to completely rip out a feature we had built with Slate and had to reimplement a new version from scratch with Lexical. So far we have no issues other than those inherent to rich text editing.

We're trying to choose between Lexical and Slate at work. Do you have any examples that would be similar to this? https://github.com/ianstormtaylor/slate/blob/main/site/examp...

If you are going to customise a ton of functionalities and/or implement new functionality I suggest using SlateJS. If not, have a look at Sun editor.

You definitely need to give Slate (https://github.com/ianstormtaylor/slate) a try - the best editor framework I've used.

Slate: Looks very promising, but it's for React. (Someone has floated the idea of making it framework-agnostic, but the maintainers haven't committed to that goal yet.)