What is EJS and what are its top alternatives?
Top Alternatives to EJS
- Handlebars.js
Handlebars.js is an extension to the Mustache templating language created by Chris Wanstrath. Handlebars.js and Mustache are both logicless templating languages that keep the view and the code separated like we all know they should be. ...
- React
Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. ...
- Pug
This project was formerly known as "Jade." Pug is a high performance template engine heavily influenced by Haml and implemented with JavaScript for Node.js and browsers. ...
- JSX
It is designed to run on modern web browsers. It performs optimization while compiling the source code to JavaScript. The generated code runs faster than an equivalent code written directly in JavaScript. ...
- Mustache
Mustache is a logic-less template syntax. It can be used for HTML, config files, source code - anything. It works by expanding tags in a template using values provided in a hash or object. We call it "logic-less" because there are no if statements, else clauses, or for loops. Instead there are only tags. Some tags are replaced with a value, some nothing, and others a series of values. ...
- TypeScript
TypeScript is a language for application-scale JavaScript development. It's a typed superset of JavaScript that compiles to plain JavaScript. ...
- Smarty
Facilitating the separation of presentation (HTML/CSS) from application logic. This implies that PHP code is application logic, and is separated from the presentation ...
- Jinja
It is a full featured template engine for Python. It has full unicode support, an optional integrated sandboxed execution environment, widely used and BSD licensed. ...
EJS alternatives & related posts
- Simple106
- Great templating language77
- Open source50
- Logicless36
- Integrates well into any codebase20
- Easy to create helper methods for complex scenarios10
- Created by Yehuda Katz7
- Easy For Fornt End Developers,learn backend2
- Awesome1
- W0
related Handlebars.js posts
- Components774
- Virtual dom657
- Performance567
- Simplicity491
- Composable438
- Data flow176
- Declarative162
- Isn't an mvc framework124
- Reactive updates114
- Explicit app state111
- JSX39
- Learn once, write everywhere23
- Uni-directional data flow19
- Easy to Use17
- Works great with Flux Architecture14
- Great perfomance10
- Built by Facebook8
- Javascript7
- Speed5
- TypeScript support5
- Feels like the 90s4
- Hooks4
- Awesome4
- Scalable4
- Easy to start4
- Server Side Rendering3
- Fancy third party tools3
- Props3
- Obama3
- Server side views3
- Functional3
- Scales super well3
- Excellent Documentation3
- Cross-platform3
- Rich ecosystem2
- Start simple2
- Allows creating single page applications2
- Sdfsdfsdf2
- Beautiful and Neat Component Management2
- Very gentle learning curve2
- Has functional components2
- Simple2
- Closer to standard JavaScript and HTML than others2
- Super easy2
- Has arrow functions2
- Strong Community2
- Great migration pathway for older systems2
- SSR2
- Fast evolving2
- Simple, easy to reason about and makes you productive2
- Just the View of MVC2
- Sharable1
- Every decision architecture wise makes sense1
- Permissively-licensed1
- Split your UI into components with one true state1
- Fragments1
- Recharts0
- Requires discipline to keep architecture organized36
- No predefined way to structure your app23
- Need to be familiar with lots of third party packages22
- JSX9
- Not enterprise friendly7
- One-way binding only5
- State consistency with backend neglected2
- Bad Documentation2
- Paradigms change too fast1
related React posts









I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.
I picked up an idea to develop and it was no brainer I had to go with React for the frontend. I was faced with challenges when it came to what component framework to use. I had worked extensively with Material-UI but I needed something different that would offer me wider range of well customized components (I became pretty slow at styling). I brought in Evergreen after several sampling and reads online but again, after several prototype development against Evergreen—since I was using TypeScript and I had to import custom Type, it felt exhaustive. After I validated Evergreen with the designs of the idea I was developing, I also noticed I might have to do a lot of styling. I later stumbled on Material Kit, the one specifically made for React . It was promising with beautifully crafted components, most of which fits into the designs pages I had on ground.
A major problem of Material Kit for me is it isn't written in TypeScript and there isn't any plans to support its TypeScript version. I rolled up my sleeve and started converting their components to TypeScript and if you'll ask me, I am still on it.
In summary, I used the Create React App with TypeScript support and I am spending some time converting Material Kit to TypeScript before I start developing against it. All of these components are going to be hosted on Bit.
If you feel I am crazy or I have gotten something wrong, I'll be willing to listen to your opinion. Also, if you want to have a share of whatever TypeScript version of Material Kit I end up coming up with, let me know.
- Elegant html134
- Great with nodejs89
- Very short syntax57
- Open source56
- Structured with indentation53
- Free23
- It's not HAML5
- Gulp5
- Clean syntax4
- Readable code4
- Easy setup4
- Difficult For Front End Developers,learn backend4
- Really similar to Slim (from Ruby fame)4
- Disdain for angled brackets2
related Pug posts
related JSX posts
- Dead simple templating29
- Open source12
- Small8
- Support in lots of languages1
related Mustache posts
TypeScript
- More intuitive and type safe javascript163
- Type safe97
- JavaScript superset73
- The best AltJS ever46
- Best AltJS for BackEnd27
- Powerful type system, including generics & JS features14
- Nice and seamless hybrid of static and dynamic typing10
- Aligned with ES development for compatibility9
- Compile time errors9
- Structural, rather than nominal, subtyping6
- Angular5
- Starts and ends with JavaScript3
- Garbage collection1
- Code may look heavy and confusing4
- Hype3
related TypeScript posts
Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.
Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.
After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...
I picked up an idea to develop and it was no brainer I had to go with React for the frontend. I was faced with challenges when it came to what component framework to use. I had worked extensively with Material-UI but I needed something different that would offer me wider range of well customized components (I became pretty slow at styling). I brought in Evergreen after several sampling and reads online but again, after several prototype development against Evergreen—since I was using TypeScript and I had to import custom Type, it felt exhaustive. After I validated Evergreen with the designs of the idea I was developing, I also noticed I might have to do a lot of styling. I later stumbled on Material Kit, the one specifically made for React . It was promising with beautifully crafted components, most of which fits into the designs pages I had on ground.
A major problem of Material Kit for me is it isn't written in TypeScript and there isn't any plans to support its TypeScript version. I rolled up my sleeve and started converting their components to TypeScript and if you'll ask me, I am still on it.
In summary, I used the Create React App with TypeScript support and I am spending some time converting Material Kit to TypeScript before I start developing against it. All of these components are going to be hosted on Bit.
If you feel I am crazy or I have gotten something wrong, I'll be willing to listen to your opinion. Also, if you want to have a share of whatever TypeScript version of Material Kit I end up coming up with, let me know.
related Smarty posts
- It is simple to use7
related Jinja posts
I have learned both Python and JavaScript. I also tried my hand at Django. But i found it difficult to work with Django, on frontend its Jinja format is very confusing and limited. I have not tried Node.js yet and unsure which tool to go ahead with. I want an internship as soon as possible so please answer keeping that in mind.