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.

import { unstable_noStore as noStore } from "next/cache"; import Link from "next/link"; import { CreatePost } from "~/app/_components/create-post"; import { getServerAuthSession } from "~/server/auth"; import { api } from "~/trpc/server"; export default async function Home() { noStore(); const hello = await api.post.hello.query({ text: "from tRPC" }); const session = await getServerAuthSession(); return (

Create T3span> App h1>

First Steps →h3>

Just the basics - Everything you need to know to set up your database and authentication. div> Link>

Documentation →h3>

Learn more about Create T3 App, the libraries it uses, and how to deploy it.div> Link> div>

{hello ? hello.greeting : "Loading tRPC query..."}p>

{session && Logged in as {session.user?.email}span>} p> {session ? "Sign out" : "Sign in"} Link> div> div> div> main> ); } async function CrudShowcase() { const session = await getServerAuthSession(); if (!session?.user) return null; const latestPost = await api.post.getLatest.query(); return (

{latestPost ? (

Your most recent post: {latestPost.name}p> ) : (

You have no posts yet.p> )} div> ); }

I thought he was making stuff up - "t3 stack vs t4 stack". But about 2 minutes in, I realized that I'd heard of a few things that he's talking about so I looked it up and they're real!

I think it's possible everything he's saying is true, more or less. LOL

t3: https://create.t3.gg

t4: https://t4stack.com

We start with a project that was bootstrapped with create-t3-app. For internationalization we use next-intl and set it up as described in the getting started guide. With this initial project setup we can jump into implementing localized error messages.

I used create-t3-app to scaffold the Next.js app, with TypeScript, Prisma, and "app router" enabled in the options. You can also use create-next-app for the job and install Prisma manually.

I agree that the quantity of publicly available code isn't the most reliable indicator of someone's seniority.

My issue with this individual arises from the discrepancy between his public claims of significant expertise in the content he produces. He positions himself as a highly experienced developer, attracting a large following of junior developers who take his advice at face value.

I am trying to collect data points supporting his claims of seniority. For instance, his website prominently features a statement that he is the creator of the T3 Stack. However, a review of the contributor statistics for the T3 Stack (https://github.com/t3-oss/create-t3-app/graphs/contributors)... minimal contributions from him, which raises questions about the validity of his claims.

I would recommend - https://create.t3.gg/

It uses the following, which as of late are pretty well know and common, so you can punch in your problems to stackoverflow, google, or chatgpt and get some pretty good answers.

It uses:

Nextjs (React), typescript, trpc (typescript rpc), auth, tailwind, and Prisma (ORM)

Though of course these could go out of fashion tomorrow, but I don't think the essential idea behind these libs and frameworks are that wacky, unique or unordinary.

Prisma ORM, is a little opinionated, and you could swap it out for Drizzle, which is basically typescript side sugared SQL.

TRPC might be also be a little sticky because it is tied to typescript, this is the tradeoff for the buttery smooth coupling for the fullstack experience. I think there exists a typed-rest solution out there, but haven't used it.

Personal anecdata, I used this stack for a little hobby project and it was FUN.

Open SaaS was built with Typescript, and because it’s a full-stack app, type safety from the back-end to the front-end can be a real lifesaver. I mean, some opinionated stacks have gotten hugely popular on this basis.

Let's start by creating a Next.js application. We will use the T3 stack (TypeScript, TailwindCSS, and Prisma ORM) for this tutorial to skip installing and configuring all the dependencies which is out of the scope of this article. You can find more information about the T3 stack.

https://github.com/t3-oss/create-t3-app

You still would need to add Stripe but there are so many examples publicly available that it should be straight forward