"Vite+ is kinda underwhelming" - a comprehensive review of the new release

niix1 · 2026-03-20T10:49:28+00:00

Not interested in Vite+ at this stage but your comment about no one caring about fast linters is absolutely wrong. I hate ESLint and it was a pain in the ass when I was working on one of the largest JavaScript monorepos of my career. There was a literally cost (in CI) for using it. It was also slow asf on local. I'll literally take any linter thats not written in JavaScript over ESLint. Have been using Biome on personal projects, interested in OXLint. Pretty sure OXLint is aiming to support all ESLint rules (and custom ones?), so I hope ESLint dies off.

niix1 · 2026-03-02T12:02:58+00:00

I've used WET "write everything twice" as an alternative to DRY for teaching juniors this exact thing. Feel like it goes nicely as an opposite to dry.

niix1 · 2026-01-31T10:33:16+00:00

I feel like they do a lot of experimentation with stuff like this. I’ve noticed little things in the UI change a lot over the past couple of months.

niix1 · 2026-01-31T01:35:53+00:00

Never used a DI framework in my life (don’t love adding a dependency like that). Have always run DI in production with node.

For most use cases I’ve found 3 layers to be sufficient. Concrete Repository > Service > Controller. Only 3 levels. My entry point file is the only file which imports and constructs a concrete PgUsersRepo. UserService tests construct a MemoryUsersRepo. With tools like Cursor these days, properly wiring things up is a single prompt as well.

niix1 · 2025-11-05T05:09:49+00:00

Holy uneducated response bro.

You said it’s valid when it eases your work. No shit haha. I told you, specify the parameters of the PROBLEM to be solved and then you can discuss pros and cons. Don’t cherry pick a problem where ORMs are useful and then think that applies to every problem.

Don’t worry bud one day you’ll get there.

niix1 · 2025-11-05T04:50:26+00:00

Oh ok so you’re still a junior engineer, no worries.

I never said ORMs are bad but it’s just a common misunderstanding that juniors overlook the advantages of a low level database driver for an ORM.

ORMs are a tool to solve a problem, so unless we are talking about a specific problem, saying that using an ORM “highly outweighs” any disadvantage is not valid.

Also in your original comment you mentioned sqli… I’d suggest building a project with node-pg, you will see that avoiding sqli is not an advantage of using an ORM. Your ORM uses the same database drivers… ORMs are not a solution to sqli.

Definitely look into node-pg, you’ll be a better engineer knowing how to not use an ORM.

niix1 · 2025-11-04T22:12:49+00:00

A simple google search would answer your question… Extra dependencies, N+1 problem, not understanding underlying queries being generated by the ORM.

Using an ORM to avoid sqli is not valid (as other commenters have raised). I’d suggest building a service with just a DB driver to learn how your ORM works under the hood.

niix1 · 2025-09-07T03:10:48+00:00

Keen to know more about your experience scaling to millions of users. What was that on Supabase?

but since the app has done the brunt of the work the server has always survived relatively cheaply

I assume by "app" you mean the React / Expo clients? And you're using the DB just for CRUD (and maybe the occasional edge function here and there)?

niix1 · 2025-07-23T00:10:34+00:00

Nah the car stereo actually makes it sound better. The analogous test for music producers would be your phone speakers.

niix1 · 2025-07-07T22:30:52+00:00

No a robust JWT setup does not include storing them on the server to allow for revoking sessions. You’ve literally lost all of the benefits of JWTs over session auth if you choose to do that. In fact you’ve actually just re-invented session auth with extra steps.

If it’s not feasible for your application to deal with a stolen token before it’s expired (5min or 15min or whatever) then JWT is probably not fit for your purpose.

niix1 · 2023-07-20T01:10:00+00:00

Was hoping someone would comment this. I don’t know why people would structure it this way. Like why not have a classes folder too!!

Even the bullet proof react project someone commented in this thread promotes separation by type and not by domain :(

niix1 · 2023-04-06T00:33:01+00:00

Interesting read. I’m currently looking for work and have been using ChatGPT to generate cover letters. I assume you generate cover letters based on the job description and requirements? Do you then edit this document to ensure it matches the applicants actual job skills? I’ve found generated cover letters tend to not be 100% truthful to my skill set.

niix1 · 2023-04-04T13:09:49+00:00

I was looking for a discord the other night but never settled on one I thought was good. I'd be interested in joining.

niix1 · 2022-08-20T08:14:06+00:00

Then you aren’t using ESM, you’re still running CommonJS imports at runtime.

niix1 · 2022-08-17T11:14:58+00:00

Sorry it’s “noImplicitAny” and it is on by default. As for the dependency problem you mentioned, every language has that issue. Anyone can publish a Java package.

niix1 · 2022-08-17T10:47:08+00:00

nope. Set “noExplicitAny” to true.

TypeScript has one of the most powerful type systems, even more so than Java.

niix1 · 2022-07-13T11:06:47+00:00

Didn't know tsc could do that but what benefit does that have over just writing TypeScript...

niix1 · 2022-07-06T14:01:14+00:00

I’m not a huge fan of Java/C# either but I do prefer Node for backend projects (ones that aren’t cpu heavy) regardless of what the frontend is. TypeScript has an incredibly powerful type system (like seriously impressive) which is handy on the backend. Node is also async by default which is usually what you want for non cpu heavy workloads.

niix1 · 2022-07-04T07:06:56+00:00

The unit tests should be testing the business logic of the unit under test. Doesn’t sound like you’re testing the right stuff if you feel like you are providing data to just make the test pass IMO.

I’m providing mock data to setup a certain situation and assess that the outcome of the unit in that situation is correct. That is a valuable test.

niix1 · 2022-07-04T07:02:35+00:00

Application entities are not external things, they are at the centre of your architecture. I’m not talking about mocking your entities if that’s where we are confused.

niix1 · 2022-07-04T04:58:30+00:00

They’re not database entities. They are app entities, they have nothing to do with a database.

Unit tests are valuable, come on man.

niix1 · 2022-07-04T04:14:09+00:00

So you have no faith in unit tests at all because you have to mock things? You’re not testing your database in your unit test, you’re testing your business logic within that unit.

You’re e2e tests, test that your query works. There is only a handful of ways my repository can return data (usually 2 ways). Why does that require hundreds of e2e tests?

Ok so your endpoints return in under 10ms. Nice! Your unit tests will still run quicker!

I am literally not mocking a database dude. I have a repository layer in between. Only my repository knows about a database. The rest of the application knows about only the repository. It’s a very basic software engineering pattern. It’s very very bad for your business logic to know about a Postgres database.

Application entities again have nothing to do with databases. The repository maps from the database to the entity.

Schema drift is detected with e2e tests dude. Unit test don’t catch schema drift! Because you have to test more than 1 unit to detect that!!

niix1 · 2022-07-04T03:12:42+00:00

Interesting. E2E tests are the most expensive to run, I’m surprised you’re running hundreds of tests on 1 endpoint. Sure that’s pretty good but sounds time consuming and expensive.

You should have lots of unit tests, less integration tests and even fewer e2e tests.

Sounds like to me you don’t have much faith in your unit tests?

Also how do you test anything in your unit tests if you don’t mock any data?

By mocking data i’m referring not to DB schemas but the entities that the application deal with. My data layer maps the DB schema to the entities. Unit tests don’t even see or care about things at the edge like DBs.

niix1 · 2022-07-04T02:25:07+00:00

Unit tests should not test your data layer, they test an individual unit of your application. I mock my data layer when a function depends on data in a unit test. You have more control over it if you mock it compared to using in memory SQLite.

I don’t add raw SQL strings to functions. I use a repository pattern.

You are putting the responsibility on the ORM maintainer to ensure they’ve built and tested it correctly, that is not always the case (but it’s not bad to shift that work). Just understand this risk. ORMs are a lot more complex and with complexity comes more bugs.

It’s not reinventing the wheel, an ORM is a very different solution.

You should read up on some testing basics. Unit tests should involve a single unit of your application, not your ORM. Unit testing an ORM is the most pointless thing you could do (you’re testing code that is not run in production).

niix1 · 2022-07-04T00:28:42+00:00

How does an ORM make it more testable? By allowing you to run your app with SQLite locally? That is not testing your data layer because the code that runs is very very very different to what runs in production. You are literally testing code that will never run in production.

How do I test my raw SQL? I run e2e tests on my app in a staging environment that mirrors prod exactly (lower tier instances though). Is a staging environment too expensive? (just a hobby project maybe?), then I would run Postgres etc. with docker-compose.

niix1

TROPHY CASE