Biome is a fork of Rome, which was originally an ambitious tool written in Rust but abandoned in October 2023. It includes both a linter and a formatter, putting an end to the time-consuming difficulties associated with reconciling ESLint and Prettier rules.

When I saw the release of bun six months ago, I was not that hyped as I saw a tool that had similar ambitions, Rome, and dissapointed many. But it was different this time. It really is a drop in replacement for Node.js so you can start using it by replacing the npm and node commands in your package.json file. The main feature that captured my interest was the ability to use require and import statemtents in the same file. This allows you to keep using CommonJS modules and use import statemtents for any new modules that drop support for it. The only catch I could find so far is that if you decide to mix import and require statements, you cannot use module.exports but instead use export statement. I did exactly that and now I have a fully functional backend with admin panel that won't make your head scratch fighting with CommonJS and ESModules.

Once you build a simple Vite backend integration, try not to complicate Vite's configuration unless you absolutely must. Vite has become one of the most popular bundlers in the frontend space, but it wasn't the first and it certainly won't be the last. In my 7 years of building for the web, I've used Grunt, Gulp, Webpack, esbuild, and Parcel. Snowpack and Rome came-and-went before I ever had a chance to try them. Bun is vying for the spot of The New Hotness in bundling, Rome has been forked into Biome, and Vercel is building a Rust-based Webpack alternative.

It definitely existed by the time rome_console/biome_console was created! The crate was created 2 years ago[1] and miette was released more than 2 years ago[2]. By the time rome_console was created miette was on v4, so presumably somewhat mature.

[1]: https://github.com/rome/tools/commits/main/crates/rome_conso...

[2]: https://crates.io/crates/miette/versions

Biome formats and lints your JavaScript and TypeScript code in a fraction of a second. Biome is the community successor of Rome Tools [0].

As part of this announcement, we have released the first stable version of Biome [1]. Join us on our Discord [2] and support us via our open collective [3].

I am one of the main maintainers of Biome. I will be happy to answer any questions :)

[0] https://github.com/rome/tools

I have no idea how true this is, but the source of the claim seems to come from here:

https://github.com/rome/tools/discussions/4302

"But in short, the company Rome Tools ran out of funding, so the core team of last year are no longer working on the project."

For now, Rome implements most of the ESLint recommended rules (including TypeScript ESLint) and some additional rules that are enabled by default. In the future, you can expect a recommended preset that is a superset of the ESLint recommended preset. So if you're not heavily customising ESLint, you should be able to use Rome.

Otherwise, most of the rules are not fine-tunable in the way that ESLint is. Rome tries to provide the experience that Prettier provided in the formatting tool: good defaults for a near-zero configuration experience. It tries to adopt the conventions of the JS/TS community. Still, some configuration is provided when the community is divided on some opinions (e.g. space vs. tab indentation, semicolons or as-needed semicolons, ...).

There is an open issue [1] for listing equivalent rules between ESLint and Rome. Expect more documentation in the future, and maybe a migration tool.

If I had been one of the founders of Rome, I could have pushed for more compatibility with ESLint. In particular, using the same naming conventions and thus the same names for most rules, and recognising ESLint ignore comments.

[1] https://github.com/rome/tools/issues/3892

Today we are going to talk about Rome. According to their github page

I must say, although it doesn't (of course) have anywhere near the configuration or plugin-capability of eslint, I've found Rome impressive so far. I have access to a range of PCs and the performance boost of a compiled binary makes a pretty big difference on a large repo on a slower machine.

Fast compilation seems very appealing. It is one of the main reason why I am interested into Go and Zig.

I recently started working with Rust for contributing to projects like Rome/tools [1] and deno_lint [2]. The compilation and IDE experience is frustrating. Compilation is slow. I am afraid that this is rooted to the inherent complexity of Rust.

[1] https://github.com/rome/tools

[2] https://github.com/denoland/deno_lint

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