Node.js Framework: Scepticism, Problems and Yet Another Framework
Tags: javascript, typescript, node
Published: 2019-06-14 08:11:29

---
title: Node.js Framework: Scepticism, Problems and Yet Another Framework
published: true
description: 
tags: #javascript #typescript #node
---

## Scepticism

Some responses I saw when someone posting about a new TypeScript framework to the public were vary, some of them positive feedback but mostly top comments were negative responses such as:

*Look like all features already there on {Nest, LoopBack} why don't you consider to contribute to them?*

*I don't need a framework for server side TypeScript, I can write my own fancy decorated framework within less than 200 lines of codes.*

Or even 

*Congratulation, you just turned JavaScript into a shittier version of Java.*

The last one is rude, but can't completely disagree with it. Since the early version of TypeScript language the most successful framework based on TypeScript was Angular 2. It's a great UI framework with a strong opinion with a lot of Java-style best practices in it. It came with built-in dependency injection and decorator based configuration. Success story of Angular 2 inspires other TypeScript frameworks (UI and Server) to use similar features. 

That fact make TypeScript atmosphere more smell Java-ish than be flexible like JavaScript. People from static type language might eager with it, but people that use dynamic type language frequently especially from JavaScript users will give the opposite opinion.

## Problems

I couldn't agree more that you can write your own TypeScript framework with decorator based configuration with less than 200 lines of codes. I even proof it myself. I created [a tiny framework](https://github.com/ktutnik/my-own-ts-framework) with decorator based routing, simple parameter binding and optional dependency injection only with 175 lines of code.

But, I doubt that you can write a robust and secure application easily with framework above. Even if you can, you don't use the power of TypeScript optimally. I believe you'll end up creating a verbose version of application that was nicely implemented in JavaScript. For example you keep creating schema to specify data type for your domain object, for example Mongoose schema and Joi schema for validation, while keep creating another class or interface for the domain model to make it type safe (to make compiler and IDE happy).

When enabled, TypeScript has ability to extract metadata (reflection) during runtime. With a proper reflection library a framework can understand the data type properly. This features can be used to create the schema in the background and use it for further process such as validation, data conversion etc.

## And Yet Another Framework

[Plumier](https://github.com/plumier/plumier) is a new Node.js framework uses TypeScript as its primary development language. Plumier built based on issues described above. Its intended to make developing time with TypeScript delightful. 

Plumier built from ground up using dedicated reflection library, so it's uses the power of TypeScript optimally. It has features that mostly uses rich metaprogramming features such as:

* Route generated using code convention. 
* Validation and type conversion without schema configuration.
* Static route analysis.
* Declarative authorization.
* Refined middleware pipeline to support async/await.
* Fast and lightweight.
* Unopinionated.

If this post doesn't get rid of your scepticism, you can read the full story on Hacker Noon story below on how the framework was built. 

{% medium https://hackernoon.com/i-spent-a-year-to-reinvent-a-node-js-framework-b3b0b1602ad5 %}

## Support The Project

The hardest part of building a framework is building and maintain a solid community, if you think Plumier match with your need, kindly help make Plumier a better future by support the project on [GitHub](https://github.com/plumier/plumier).