4 ms·
My current tools of choice for server-side are Python 3 + Django + Django REST Framework (DRF). I want to really get into Node, but developing with it currentl
by ralmidani 9y ago
My current tools of choice for server-side are Python 3 + Django + Django REST Framework (DRF).
I want to really get into Node, but developing with it currently feels like I'm Dr. Frankenstein hacking and stitching his monster together.
I realize Node developers tend to prefer small, focused libraries rather than big, monolithic frameworks. But taken to an extreme, this results in a codebase that has litle beauty, consistency, or symmetry.
Want to initialize an Express app? Don't use the new keyword. Want to declare a Mongoose schema? You have to use the new keyword.
Express uses callbacks extensively, but for Mongoose I can configure promises (oh, should I also install and import Bluebird or just use global promises?)
And really, why is body-parser installed separately from Express?
I'm not disparaging Node in order to elevate Python, Django, and DRF. I really want to embrace Node and build fast, elegant, real-time, universal ES 2015+ Web apps. But as it stands now, exploring the Node ecosystem is exhausting and frustrating.
Edit: if nobody builds a universal, consistent, ES 2015+ framework for Node, I fully intend to do it myself.
- kerryritter 9y agoI have the same complaints. I've found NestJS (https://nestjs.com https://nestjs.com) to be a wonderful solution for a lot of what you're talking about. There's a few recipes to get you up and rolling with a real framework and also an ORM (TypeORM or Mongoose). Highly recommend.
- deathtrader666 9y agoIf you want to build fast, elegant, real-time, consistent web apps for 2017 and onwards, take a look at Elixir and the Phoenix framework.
- ralmidani 9y agoElixir/Phoenix looks amazing. I actually flirted briefly with Rails, so looking at the docs for Phoenix, I sort of understood what was going on (even without having learned Elixir). But doesn't using Phoenix still require JavaScript for the client-side? One of the benefits of Node is the potential for sharing code between client and server.
- thom_nic 9y ago> sharing code between client and server Never happens as much as you would think it might, except maybe for some very simple common utility functions. There is some benefit to consistent tooling (e.g. all you need is node+npm, then `npm i` and `npm run whatever`) for both client and server, but I have yet to find a project or framework that shares even the obvious stuff like domain model classes well.
- ralmidani 9y agoIt has not yet been done successfully, but that does not mean it cannot be done. I have used Django and Ember together for a couple of projects, and having to define model classes twice is extremely wasteful in a large application. Not to mention having to use a third library for client-side validation (Ember does not do validations out-of-the-box), even though Django has most (if not all) the information needed for thorough validation sitting on the server. In lieu of code-sharing, Django REST Framework does have schema generation support, but no major client-side framework supports it yet.
- tbrock 9y agoI hear you. Body parser is now bundled with express though so at least that is getting better.
- thom_nic 9y ago> Express uses callbacks extensively This is true, Express goes way back to Node's pre-1.0 days before promises were a thing. For a more modern NodeJS experience, I'd recommend Koa http://koajs.com/ http://koajs.com/. Rule number one for pain-free JS development: do everything with promises, if not async/await. Koa is still "lightweight" in the sense that you piece together your middleware + request handler chain similar to Express (or Flask!) but it's just as capable once you've added what you need.