Make things pure ... to become lean.
leanup js
The @leanup ecosystem stands for a lightweight and pure way for application development in JavaScript/TypeScript.
- Motivation
- Our home stories
- What makes the difference
- Principles
- Arguments
- Demo's
- Tools
- Ecosystem structure
- Alternatives
Motivation
- Learnability
- Controllability
- Universality
- Flexibility
- Scalability
- Durability
- Transparency
Our home stories
In 2021
Transpilers
We switched from Babel to esbuild and from esbuild to swc (without Angular and Vue with proprietary template notation). And we can switch again if we want.
The performance of esbuild and swc are almost twice as fast as with the classic configuration. But there is currently no noticeable difference in performance between esbuild and swc.
Frameworks
We added two more frameworks (Lit and Solid) without any problems, without having to change the basic stack.
We have switched our Demo-Template from Bootstrap to Tailwindcss and from Tailwindcss to WindiCSS and now use the automatic application-specific CSS generation.
Bundlers
We tried two new bundlers (Vite and Snowpack) and integrated them for most frameworks. Alternatively, they can be installed alongside or instead of webpack.
What makes the difference
Stop the transitive knowledge.
We use the minimal configuration and build no overhead stuff on top of the popular tools and make every native command transparent.
Principles
- convention over configuration
- pure commands under the hood
- don't repeat yourself
- following the generic instead of the influenced way
- keep the dependencies always up to date
Arguments
The arguments for and against this concept are documented here:
Pro
- select only one pure and popular tool for each use case (e.g. bundling, unit-test)
- there are extensible configuration files for each tool
- due to the flat dependencies we can always stay up to date
- the CLI bundles all the necessary tools in a portable/scalable way
- the risk to get vulnerabilites in dependencies is lower
- leanup's own code is kept to a minimum
Contra
- please give feedback
- please show us your perspective
Demo's
There are some working examples:
Tools
| Tool/Technology | Description | Status | Note | Rating |
|---|---|---|---|---|
| TypeScript | Language | ✔️ | ready |  |
| Webpack | Bundler | ✔️ | ready |  |
| Snowpack | Bundler | ⌛ | in progress |  |
| Vite | Bundler | ⌛ | in progress |  |
| esbuild | Transpiler | ✔️ | ready |  |
| swc | Transpiler | ✔️ | ready |  |
| Babel | Transpiler | ✔️ | ready |  |
| Mocha | Unit-Test-Runner | ✔️ | ready |  |
| Chai | Assertion | ✔️ | ready | |
| Sinon | Mocking | ✔️ | ready |  |
| NYC | Code-Coverage | ✔️ | ready |  |
| ESLint | Code-Checker | ✔️ | ready |  |
| Nightwatch.js | E2E-Test-Runner | ✔️ | ready |  |
| Allsure | Report | ✔️ | ready | |
| Cucumber | BDD | ✔️ | ready |  |
| robotframework | BDD | ⌛ | will be evaluated | |
| Storybook | Documentation | ⌛ | in progress |  |
| OpenAPI | API | ✔️ | ready | |
| GraphQL | API | ✔️ | ready |  |
| Workbox | PWA | ✔️ | ready |  |
| Lerna | Mono-Repo | ✔️ | ready |  |
| Ant-Design | Design-System | ✔️ | proved |  |
| Bootstrap | Design-System | ✔️ | proved |  |
| Material | Design-System | ✔️ | proved |  |
| Tailwindcss | Design-System | ✔️ | proved |  |
| WindiCSS | Design-System | ✔️ | proved |  |
| Nexus IQ | Vulnerabiliy-Gate | ✔️ | ready | |
| Less | CSS | ✔️ | ready |  |
| Sass | CSS | ✔️ | ready |  |
| PostCSS | CSS | ✔️ | ready |  |
| TSArch | Architecture | ⌛ | in progress |  |
| Webhint | Webhint | ✔️ | moved *** |  |
| TestCafe | E2E-Test-Runner | ⌛ | will be evaluated **** |  |
| TSLint | Code-Checker | ❌ | removed ** |  |
| Cypress | E2E-Test-Runner | ❌ | excluded * |  |
* Arguments agains Cypress:
- reinvent wheel
- detect css selectors
- BDD test syntax
- principals
- large tooling
- a lot of binaries
- many dependencies
- ci integration vs selenium hub
It is difficult to keep focus with Cypress as it is more a nice tool than an effective tool. It is expected that a lot of time will be invested to justify the requirements of a project.
** TSLint is deprecated.
*** Webhint is not practical for the development of components, since component tags often have no relation to standard HTML. In addition, the webhint package alone is over 100 MB in size. I have good by using a IDE webhint plugin, like VSCode webhint.
**** TestCafe The idea that defined TestCafe architecture was that you don't really need an external driver to run end-to-end tests in the browser. That's interesting.
Ecosystem structure
Vanilla Java-/TypeScript are supported by default. That means for example custom elements and any plain Java-/TypeScript code.
@leanup/cli✔️@leanup/cli-vanilla(optional) ✔️
Frameworks
Vanilla Java-/TypeScript are supported by default. That means for example custom elements and any plain Java-/TypeScript code.
The selection of the following frameworks depends in parts on the following references:
Currently the following framework extensions are available:
@leanup/cli-angular✔️@leanup/cli-angularjs✔️@leanup/cli-aurelia✔️@leanup/cli-inferno✔️@leanup/cli-lit-element✔️@leanup/cli-preact✔️@leanup/cli-react✔️@leanup/cli-solid✔️@leanup/cli-svelte✔️@leanup/cli-vue✔️@leanup/cli-vue3✔️
Extensions
A separate package contains some nice but not required addons for webpack.
@leanup/cli-addons✔️@leanup/cli-cucumber✔️@leanup/cli-graphql✔️@leanup/cli-pwa✔️@leanup/cli-webhint✔️
Thinks
There a separate packages for important application features.
@leanup/git-hooks✔️@leanup/form✔️@leanup/lib✔️@leanup/ui⌛ (in progress)
Alternatives
- Angular
- Neutrino
- Rome
