greenwood VS Scrawl-canvas

I have a project in called Greenwood that can probably help here if you're interested to check it out. Made to easily start with HTML (or markdown) and focused on web standards to make learning and development easy and familiar. Works great with Web Components and can even pre-render them! https://github.com/ProjectEvergreen/greenwood

Either is pretty easy to get started with and keep you nicely aligned with web standards if that's of interesting to you. I have a project that could help you work with either of those option you are so inclined, with the getting started guide of the website giving a brief overview of how to get started with native web components. https://www.greenwoodjs.io/

My project Greenwood might be able to help here, depending on what your current setup looks like. Inspired by the old HTML Includes spec, I created a plugin for replicating this sort of edge side include behavior.

I do, and that's a big part of why I started working on Greenwood. I wanted to always just be able to start from an index.html file, but also have some nice minimal glue like a dev server, file based routing, markdown, and leveraging Web Components for templating and SSR.

That's a big part of why I started working on Greenwood. I wanted to always just be able to start from an index.html file, but also have some nice minimal glue like dev server, file based routing, markdown, and even leveraging Web Components for templating and SSR. Loving learning even more about the web and so for that reason I like to think of it less as a framework, and instead as your full-stack workbench for the web! https://github.com/ProjectEvergreen/greenwood

I created my project Greenwood as a way to support web standards based development (e.g. not a meta framework) that can be as easy to start with as an index.html, or a markdown file, and can do most architectures; SPA / CSR, MPA, SSR. I like to think of it as your full-stack workbench for the web.https://github.com/ProjectEvergreen/greenwoodStill a WIP and continuing to improve our design and feature set, so feel to give it a try, and any and all feedback welcome! Check out our blog if your curious about what we've been up to in 2022, and there will be a post soon about our plans for 2023

Not sure if this would be of interest to you, but my project Greenwood let’s you start with just HTML / markdown and standard web dev to build out the rest, with a focus on supporting Web Components, even for SSR. https://www.greenwoodjs.io

I like to think of my project Greenwood not so much of a framework, for similar sentiments as what you describe, and have come to refer to it as a "workbench for the web"; emphasizing web standards based development (e.g. so not a meta framework) and has great support for Web Components. (full stack web components, ftw!) https://github.com/ProjectEvergreen/greenwood

My project Greenwood might be able to help. It supports web standards based development (e.g. not a meta framework) and has great support for Web Components. As easy to start as an index.html file or a markdown file, and can do most architectures; SPA / CSR, MPA, SSR. I like to think of it as your workbench for the web. https://github.com/ProjectEvergreen/greenwood Still a WIP and continuing to improve our design and feature set, so feel to give it a try, and any and all feedback welcome!

> working with glyphs and iterating them in reverse for RTL is brain-breaking. And line wrapping gets really complicated. It's also the most obscure because nobody has written down everything you need to know in one place

I can confirm this. I've been working on a (much simpler!) text layout engine for my canvas library over the past couple of months and the amount of complexity associated with just stamping some glyphs onto a canvas has left me screaming at my laptop on an almost daily basis. Getting a decent underline was a proud moment!

Question: did you ever find out what algorithm the various browsers are using to calculate how many words can fit on a given line? I'm almost there, except words will occasionally jump between lines when I scale the text. Really annoying!

The PR's still a work in progress, but I've got all the functionality I want in there (shaping lines to fit in non-rectangular containers, styling text, text along a non-straight line, dynamic updates, etc). Just need to test and document it all now ... https://github.com/KaliedaRik/Scrawl-canvas/pull/75

I've got myself organised and prepared a List Of Things To Do[1] to make my 2D Javascript library even better than it already is. Given that I've been working on the library for over 10 years now, and have never before set out such a list, I call this Progress!

[1] https://github.com/KaliedaRik/Scrawl-canvas/discussions/cate...

'Kay, I don't know if this anywhere close to what the OP wants, but this sort of live browser tab manipulation is possible to do using a mix of a a canvas element and the browser's Screen Capture API[1] (plus my JS canvas library, once I merge and publish the changes into its next release[2]).

This solution[3] shows the modified browser tab in a separate browser tab. I've got no idea whether it's possible to do the same sort of trick in the same tab (but probably not). I also have no idea how secure the Screen Capture API is - I'd get very nervous about doing this sort of thing when looking at my bank's online portal!

[1] https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capt...

[2] https://github.com/KaliedaRik/Scrawl-canvas/pull/57

[3] Youtube video of the effect: https://www.youtube.com/watch?v=hCi6LmKMAo0

My canvas library's README[1] has a video embedded in it. FWIW I'm not convinced it adds anything to the library's sales pitch.

[1] https://github.com/KaliedaRik/Scrawl-canvas

> And I’m just mentioning some of the unfixable problems with this approach

I agree that using a canvas instead of leveraging existing accessibility supplied by HTML/CSS/JS and the DOM is an accessibility nightmare.

However, I disagree that canvas accessibility issues are "unfixable". Difficult? Yes. But not unfixable. In my view, the element works best in partnership with its wider environment (HTML/CSS/JS and the DOM), not as a replacement for it. With that in mind, we can start to tackle the accessibility issues you raise - fonts, links, interactions, etc.[1][2]

I have an ambition to one day become intelligent enough to understand/code in Rust, and I'm really glad to see that people are thinking about accessibility as a fundamental part of UIs being developed in Rust.

[1] - Which is what my JS 2d canvas library tries to do: https://scrawl-v8.rikweb.org.uk/

[2] - My thoughts on accessibility, and how I try to fix them using my library: https://scrawl-v8.rikweb.org.uk/learn/eleventh-lesson/

If, however, your company is set on this course, I very strongly suggest you use a canvas library - if only for the MVP. Here's my canvas library (spam alert!) ... even if you don't use it in your product, the library might help give you some ideas on how to overcome some of the responsive, interactive and accessibility issues you'll be facing.

Scrawl-canvas - example and another example (links to code at bottom of each page)

My personal experience as a library developer, who has written my library in JS, not TS ...

TS is an excellent choice for a lib dev starting a new project today. I can see the advantages of using TS for the library code - in particular for a library that gets popular and welcomes contributions from other developers. However TS is a nightmare for someone like me who: 1. started writing the library 9 years ago; 2. has let the library get "quite" big; and 3. has only learned to use TS in the past year (for the day job) and is nowhere near to becoming a types expert.

I've had experience of people suggesting I rewrite the library in TS. Sometimes those suggestions have been quite 'evangelical' in their tone. As an (essentially) solo developer I just don't have the time, capacity or willingness to do that work - however much the end results might please others.

I also understand that having type definitions file for the library's interface is, nowadays, a critical factor if the lib dev wants others to use the library in their projects. But writing a .d.ts file for a large, mature repo to at least help those potential users can quickly turn into a World of Hurt. I know this because I've done that work[1] and I never want to do it again.

As much as I know that TS is a Force for Good in the JS coding world, there are days when I detest it!

[1] - link to the Scrawl-canvas .d.ts file on GitHub - https://github.com/KaliedaRik/Scrawl-canvas/blob/master/sour...