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.
-
-
vitesse-modular-naiveui
If you are really into the "Vitesse" starter template created by Anthony Fu (Vue core team member) but want to use the clean architectural pattern instead of monolithic architecture, then you can clone this repo and use your own project. Have fun 🙂!
-
lexical
Lexical is an extensible text editor framework that provides excellent reliability, accessibility and performance.
-
-
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.
-
-
-
-
stencil
A toolchain for building scalable, enterprise-ready component systems on top of TypeScript and Web Component standards. Stencil components can be distributed natively to React, Angular, Vue, and traditional web developers from a single, framework-agnostic codebase.
-
I built a text annotation tool recently, first in React before rewriting it in Svelte. I found React's virtual DOM annoying, esp. when dealing with text selections + wrapping those selections with elements, etc. Svelte was just simpler in this regard (and overall, IMO).
But if you're not a frontend dev and want to use lots of off-the-shelf components, Svelte's ecosystem is much smaller than React's, so you won't have access to full-featured component libraries like Material UI, Chakra, etc. Additionally, Typescript support is stronger in React (it's mostly there in Svelte, but lacking in some areas [1]).
For both React and Svelte I found XState helpful to manage annotator state. It might not be necessary if your app isn't terribly complex (in particular, Svelte's built-in stores can handle complex state well), but I've found it a good way to think about state+events and more confidently make changes as a result.
1 - https://github.com/sveltejs/svelte/issues/4701
I love Mithril (https://mithril.js.org), even in 2022. I wrote a blog about how/why I used it for Homechart:
https://homechart.app/blog/tech-stack-ui/
+1. I also recommend this template[1] based on Vitesse, a starter project created by one member of Vue core team. It includes the NaiveUI library with many advanced components ready.
[1] https://github.com/arijs/vitesse-modular-naiveui
> "building a text-annotation based app"
I'm going to assume that you are talking about a desktop-based webapp that is also responsive, and not a native app. I also believe you when you say that you do not know where you are getting into.
I have 10+ years of experience doing front-end, with probably over a dozen React packages self-published in npm, and also tried making a rich text editor ~6 years back[1]. I actually recommend starting with no framework at all (please read on).
Creating a rich text editor might be the hardest thing you can do in "normal" front-end (excluding some more advanced "frontend" fields like 3D or games). You can either manipulate raw cursors, which will be very tricky because I'm not even sure you have access to all the right APIs (specially on mobile), or you can attempt to use Contenteditable, which is a hell of its own[2].
"All problems start with caret placing and multi browser support" [3]
That said, I believe 90% of the complexity of your app will be here, around the actual interaction with the or <div contenteditable> that you will be using. For that, no framework will really help you, at all. So my recommendation is to first get that working, which will take weeks/months and hundreds or thousands of lines of code, and then worry about placing the little hovering boxes in their place (the "UI"), which is like 10 lines of JS/CSS[4].<p>[1] <a href="https://github.com/franciscop/modern-editor" rel="nofollow">https://github.com/franciscop/modern-editor</a><p>[2] <a href="https://answerly.io/blog/my-pain-developing-a-wysiwyg-editor-with-contenteditable/" rel="nofollow">https://answerly.io/blog/my-pain-developing-a-wysiwyg-editor...</a><p>[3] <a href="https://news.ycombinator.com/item?id=27938702" rel="nofollow">https://news.ycombinator.com/item?id=27938702</a><p>[4] <a href="https://stackoverflow.com/q/4495626/938236" rel="nofollow">https://stackoverflow.com/q/4495626/938236</a>
Can you elaborate a bit more on this part, please?
> I'm thinking of building a text-annotation based app _alone in my spare time_. The core usage loop is about viewing and interacting with "visual markup" applied to a body of text. So lots of tooltips/hoverbars I guess.
Or show us a mockup... doesn't have to be anything fancy, just like a pen and paper sketch or a simple Figma.
I'm asking because it kinda sounds like you're wanting to do something like an online IDE or Google Docs, where you're manipulating a body of text in the style of a rich text editor. If that's the case, it's possible the HTML DOM model isn't quite the right fit for you... you may find it better to abstract over a Canvas or WebGL object instead of trying to shoehorn that experience into the raw DOM. That way you have full control over rendering, outside of the normal layout/styling/rendering loop. It might also make a good case for a single-page app (at least the majority of the editor itself would be, and the other stuff -- marketing, blog, etc. -- can be routed to individual pages).
In that case, it wouldn't be so much a question of "framework" in the sense of React, Vue, etc., which traditionally work on the DOM. It might be more a question of "engine", like whether to use something like PixiJS to manipulate the graphics layer vs rolling your own. State management can be done with something like Redux (even without React), or if you choose to use a frontend framework for the rest of it, you can maybe use their state solution with your rendering engine.
In addition to choosing a low-level graphics lib, you can also look at some existing rich text markup solutions. A CMS I used had a good blog post on this: https://www.datocms.com/docs/structured-text/dast#datocms-ab... along with their open-source editor: https://github.com/datocms/structured-text
A more widespread one is the toast UI editor: https://ui.toast.com/tui-editor
I know you're not just working in Markdown, but these give you an idea of what it's like to work with complex text trees in JS.
Once you have the actual text editor part figured out, choosing the wrapper around it (again, just for marketing pages, etc.) is relatively trivial compared to the difficulty of your editor app. I really like Next.js myself (if you choose React), but I don't think you could really go wrong with any of the major choices today... React/Vue/Svelte/etc. And it looks to me like the complexity of your site wouldn't really be around that anyway, but the editor portion.
Lastly: I don't think ANY JS tool or package is going to be maintained in 10 years. Frankly, 2 years is a long time in the JS ecosystem :( I'm not defending this phenomenon, I hate it too, but that's the reality of it. If long-term maintenance is a goal of yours, you might want to consider writing abstraction layers over third-party tools you use, so you can easily swap them out when future things come out (because they will). The web itself is changing too fast for libraries to keep up; instead, people just write new ones every few years. An example of this is the pathway from the Canvas to WebGL to workers to WASM (and how to juggle heavy computational vs rendering loops around)... a lot of the old Canvas-based renderers, which were super powerful in their time, are now too slow vs the modern alternatives. Nobody is going to port the old stuff over, they just make new libs. It's likely that trend will continue in the JS world (that whatever you write today will be obsoleted by a new web API in a few years).
Lastly, as an aside, TypeScript is a superset of JS... if you find a JS project/lib/plugin that you want to use, there will often be types for it made by the community (https://github.com/DefinitelyTyped/DefinitelyTyped) , or you can write your own types for it. I don't really have an opinion about TypeScript vs writing in some other language and compiling to JS, but it would probably be easier to find help (especially frontend) in the future if you stick with TypeScript instead of convoluting your stack with multiple languages. Sounds like most of your app will be clientside anyway with limited backend needs.
---------
Tech aside... have you considered partnering with a frontend dev for this? I know you said "alone", but just having someone set up the basic skeleton of such an app with you for the first month or two could be super helpful. Or a UX person to help you with some of the interactions before you start serious coding. They don't have to be with you the whole journey, but maybe they can help jumpstart your project so you can then work on adding features & polish in your spare time, instead of figuring out basic architecture? Unless, of course, that's the part you actually enjoy. In that case, don't let anyone rob of you that :)
Have fun! Sounds like a cool project.
Can you elaborate a bit more on this part, please?
> I'm thinking of building a text-annotation based app _alone in my spare time_. The core usage loop is about viewing and interacting with "visual markup" applied to a body of text. So lots of tooltips/hoverbars I guess.
Or show us a mockup... doesn't have to be anything fancy, just like a pen and paper sketch or a simple Figma.
I'm asking because it kinda sounds like you're wanting to do something like an online IDE or Google Docs, where you're manipulating a body of text in the style of a rich text editor. If that's the case, it's possible the HTML DOM model isn't quite the right fit for you... you may find it better to abstract over a Canvas or WebGL object instead of trying to shoehorn that experience into the raw DOM. That way you have full control over rendering, outside of the normal layout/styling/rendering loop. It might also make a good case for a single-page app (at least the majority of the editor itself would be, and the other stuff -- marketing, blog, etc. -- can be routed to individual pages).
In that case, it wouldn't be so much a question of "framework" in the sense of React, Vue, etc., which traditionally work on the DOM. It might be more a question of "engine", like whether to use something like PixiJS to manipulate the graphics layer vs rolling your own. State management can be done with something like Redux (even without React), or if you choose to use a frontend framework for the rest of it, you can maybe use their state solution with your rendering engine.
In addition to choosing a low-level graphics lib, you can also look at some existing rich text markup solutions. A CMS I used had a good blog post on this: https://www.datocms.com/docs/structured-text/dast#datocms-ab... along with their open-source editor: https://github.com/datocms/structured-text
A more widespread one is the toast UI editor: https://ui.toast.com/tui-editor
I know you're not just working in Markdown, but these give you an idea of what it's like to work with complex text trees in JS.
Once you have the actual text editor part figured out, choosing the wrapper around it (again, just for marketing pages, etc.) is relatively trivial compared to the difficulty of your editor app. I really like Next.js myself (if you choose React), but I don't think you could really go wrong with any of the major choices today... React/Vue/Svelte/etc. And it looks to me like the complexity of your site wouldn't really be around that anyway, but the editor portion.
Lastly: I don't think ANY JS tool or package is going to be maintained in 10 years. Frankly, 2 years is a long time in the JS ecosystem :( I'm not defending this phenomenon, I hate it too, but that's the reality of it. If long-term maintenance is a goal of yours, you might want to consider writing abstraction layers over third-party tools you use, so you can easily swap them out when future things come out (because they will). The web itself is changing too fast for libraries to keep up; instead, people just write new ones every few years. An example of this is the pathway from the Canvas to WebGL to workers to WASM (and how to juggle heavy computational vs rendering loops around)... a lot of the old Canvas-based renderers, which were super powerful in their time, are now too slow vs the modern alternatives. Nobody is going to port the old stuff over, they just make new libs. It's likely that trend will continue in the JS world (that whatever you write today will be obsoleted by a new web API in a few years).
Lastly, as an aside, TypeScript is a superset of JS... if you find a JS project/lib/plugin that you want to use, there will often be types for it made by the community (https://github.com/DefinitelyTyped/DefinitelyTyped) , or you can write your own types for it. I don't really have an opinion about TypeScript vs writing in some other language and compiling to JS, but it would probably be easier to find help (especially frontend) in the future if you stick with TypeScript instead of convoluting your stack with multiple languages. Sounds like most of your app will be clientside anyway with limited backend needs.
---------
Tech aside... have you considered partnering with a frontend dev for this? I know you said "alone", but just having someone set up the basic skeleton of such an app with you for the first month or two could be super helpful. Or a UX person to help you with some of the interactions before you start serious coding. They don't have to be with you the whole journey, but maybe they can help jumpstart your project so you can then work on adding features & polish in your spare time, instead of figuring out basic architecture? Unless, of course, that's the part you actually enjoy. In that case, don't let anyone rob of you that :)
Have fun! Sounds like a cool project.
Can you elaborate a bit more on this part, please?
> I'm thinking of building a text-annotation based app _alone in my spare time_. The core usage loop is about viewing and interacting with "visual markup" applied to a body of text. So lots of tooltips/hoverbars I guess.
Or show us a mockup... doesn't have to be anything fancy, just like a pen and paper sketch or a simple Figma.
I'm asking because it kinda sounds like you're wanting to do something like an online IDE or Google Docs, where you're manipulating a body of text in the style of a rich text editor. If that's the case, it's possible the HTML DOM model isn't quite the right fit for you... you may find it better to abstract over a Canvas or WebGL object instead of trying to shoehorn that experience into the raw DOM. That way you have full control over rendering, outside of the normal layout/styling/rendering loop. It might also make a good case for a single-page app (at least the majority of the editor itself would be, and the other stuff -- marketing, blog, etc. -- can be routed to individual pages).
In that case, it wouldn't be so much a question of "framework" in the sense of React, Vue, etc., which traditionally work on the DOM. It might be more a question of "engine", like whether to use something like PixiJS to manipulate the graphics layer vs rolling your own. State management can be done with something like Redux (even without React), or if you choose to use a frontend framework for the rest of it, you can maybe use their state solution with your rendering engine.
In addition to choosing a low-level graphics lib, you can also look at some existing rich text markup solutions. A CMS I used had a good blog post on this: https://www.datocms.com/docs/structured-text/dast#datocms-ab... along with their open-source editor: https://github.com/datocms/structured-text
A more widespread one is the toast UI editor: https://ui.toast.com/tui-editor
I know you're not just working in Markdown, but these give you an idea of what it's like to work with complex text trees in JS.
Once you have the actual text editor part figured out, choosing the wrapper around it (again, just for marketing pages, etc.) is relatively trivial compared to the difficulty of your editor app. I really like Next.js myself (if you choose React), but I don't think you could really go wrong with any of the major choices today... React/Vue/Svelte/etc. And it looks to me like the complexity of your site wouldn't really be around that anyway, but the editor portion.
Lastly: I don't think ANY JS tool or package is going to be maintained in 10 years. Frankly, 2 years is a long time in the JS ecosystem :( I'm not defending this phenomenon, I hate it too, but that's the reality of it. If long-term maintenance is a goal of yours, you might want to consider writing abstraction layers over third-party tools you use, so you can easily swap them out when future things come out (because they will). The web itself is changing too fast for libraries to keep up; instead, people just write new ones every few years. An example of this is the pathway from the Canvas to WebGL to workers to WASM (and how to juggle heavy computational vs rendering loops around)... a lot of the old Canvas-based renderers, which were super powerful in their time, are now too slow vs the modern alternatives. Nobody is going to port the old stuff over, they just make new libs. It's likely that trend will continue in the JS world (that whatever you write today will be obsoleted by a new web API in a few years).
Lastly, as an aside, TypeScript is a superset of JS... if you find a JS project/lib/plugin that you want to use, there will often be types for it made by the community (https://github.com/DefinitelyTyped/DefinitelyTyped) , or you can write your own types for it. I don't really have an opinion about TypeScript vs writing in some other language and compiling to JS, but it would probably be easier to find help (especially frontend) in the future if you stick with TypeScript instead of convoluting your stack with multiple languages. Sounds like most of your app will be clientside anyway with limited backend needs.
---------
Tech aside... have you considered partnering with a frontend dev for this? I know you said "alone", but just having someone set up the basic skeleton of such an app with you for the first month or two could be super helpful. Or a UX person to help you with some of the interactions before you start serious coding. They don't have to be with you the whole journey, but maybe they can help jumpstart your project so you can then work on adding features & polish in your spare time, instead of figuring out basic architecture? Unless, of course, that's the part you actually enjoy. In that case, don't let anyone rob of you that :)
Have fun! Sounds like a cool project.
As in every post about front-end frameworks, I must mention HTMX and Unpoly:
https://htmx.org/
https://unpoly.com/
To learn more about the concept, please take a look at Essays here:
Maybe have a look at Stencil (+ Ionic). https://stenciljs.com/
Pro:
- Simple to learn
- Doesn't change all the time
- First-class TypeScript support
- Good default UI via Ionic
- Compiles to Web Components (although to be honest, this doesn't really matter)
- Easy testing
- Ionic as a company invests in Ionic the framework + Stencil the compiler. Might be around in 10 years, altough things could change. But this is true for all frameworks.
- You basically get an iOS/Android app for free, if you just dump the output in Capacitor (also developed by Ionic the company).
Cons:
- Stencil is not very widespread as a frontend framework.
