A few months ago, I saw a tweet from @awilkinson: “I just found out how much we pay for DocuSign and my jaw dropped. What's the best alternative?”
Me being naive, I thought “how hard could would it actually be to build a free e-sign tool?”
Turns out not that hard.
In about a weekend, I built a UETA and ESIGN compliant tool. And it was free. And it cost me less than $50. Unlimited free e-sign. https://useinkless.com/
- I think it comprehensively misunderstands and mis-implements a lot of things that are important. Their “microservices” boondoggle is a whatever RPC mechanism that has no real reason to exist, their CQRS library expects the world to be a single node, their OpenAPI library is vestigial and completely separates the generation of documentation from actually validating inputs. Most of the things outside of core are rotated about 45 degrees away from where you’d expect with a holistic understanding of a web application. Stuff built by somebody who heard of a problem, not felt a problem.
- I think that the core team is bad at and refuses to improve at communicating with its community via roadmaps. Huge changes just appear, including literally breaking changes within a given major release, with little to no warning.
- I think they don’t respect what community they do have, building completely new, blessed-by-the-core-team libraries that step on existing open-source solutions in the NestJS ecosystem mostly just so the package can say “@nestjs/“ at the front of it. (Top of mind example is “@nestjs/schedule”, which is a worse take on “nest-schedule.") There isn't much personal incentive to build community tooling if the core team will swoop in and go "mine now!" without so much as a prior-work credit and it's disrespectful besides.
- They continue to build their own tooling that steps on the accepted norms and systems in the Node community. The NestJS CLI now incorporates "monorepos" that aren't Lerna or Yarn ones; they're also pushing developers to use it as their primary way of building applications, rather than invoking tsc, with the dangly carrot of "we'll write plugins for it [rather than using one of the existing ways to better handle extended compilation]". It feels like a lock-in play for future monetization (there's open rumors that Kamil is very focused on monetization, which--you do you, but as Rails and Django and even Spring showed us this stuff seems to really work better if you care about it existing to exist, and you make money off of using it) and the lack of community roadmap makes assuaging those concerns very much not a priority of the core team.
I was a big booster of NestJS a year ago and I’ve written a bunch of modules for it. I was even a personal donor to the project's Open Collective, it's the only project I've ever done that for. But I do not use NestJS for new projects because I have no confidence in the design or the leadership there and I don’t think it’s a wise use of my time anymore.
I've spent the last eighteen months using NestJS. I can simultaneously call it a good step forward in the Node space and something I wouldn't use for a new project. They've done a lot of work to build a system that, so long as you stay within very narrow lines and don't ask too many questions, feels very cohesive and consistent. The unfortunate part is that it shakes apart at speed if you don't do both of those things.
People make a lot of hay about the NestJS dependency injection system, and my intuition is that a lot of it is that it's a novel concept to a lot of the folks running into it. If you come from a Spring or related background, however, I think it's pretty clear that NestJS has a pretty critical misunderstanding of dependency injection. Modules are hardwired together--`BarModule` requires `FooModule`rather than just declaring what they need and what they export and allowing the dependency resolver to figure it out regardless of what module they come from. As-is, you cannot replace a dependency coming from `FooModule` with one, say, from `Foo2Module` without changing every consumer. It's a high-boilerplate devolved service locator rather than dependency injection.
"Pretty critical misunderstanding" has become my default description of big parts of NestJS as I've gotten deeper into its use over the last year and a half. This description really does fit a lot of aspects of the system. It often feels as though the implementors read half a description of this or that, decided "that's a great idea!", and then implemented that half-a-description...poorly. The "microservices" concept (really just RPC, and not particularly play-nice-with-others RPC) is a good example, as is the really clunky access to WebSockets. CQRS is another prime example, as they've somehow implemented single-node CQRS, made it impossible to distribute, and declared victory and went home.
It is better to not provide official support for something if that official support is going to be so full-stop awful, because that official support will choke out attempts to innovate in the space because you've already taken the mindshare for the problem at hand. Which dovetails into the problem that will probably end up putting NestJS in the dustbin as soon as somebody else comes up with a competitor: the NestJS team seems to have what feels like at best an oblivious and at worst a rivalrous relationship with their community and with Node as a whole. Over the last year they've rolled out what read to me as lock-in, don't-play-nice-with-the-ecosystem-as-a-whole "features", like their poorly intentioned CLI "monorepo tooling rather than just using lerna for multi-modulestuff like the rest of the world. Also like the future-forecasted "Nest CLI plugins" for things like linting otherwise bonkers misbehaviors[0]. As somebody who's written a bunch of open-source modules for NestJS, I consistently get the feeling that Kamil would really prefer it if developers just shut up and took his stuff and made apps (maybe paying him along the way?), rather than building their own open-source stuff alongside it. I still have a very bad taste in my mouth from the way that they just stomped on the `nest-schedule` project by added a less-featureful but otherwise identical "cron-like" gizmo to NestJS core without so much as a nod to the community member who wrote the better one before they did. The idea seems to be that NestJS isn't a community, it's a single-source vendor, and in 2020 that's weird to me.
I've used a lot of NestJS but I can't really countenance using it for new projects, and I can't recommend it to others.
Turns out not that hard.
In about a weekend, I built a UETA and ESIGN compliant tool. And it was free. And it cost me less than $50. Unlimited free e-sign. https://useinkless.com/