Hacker News Reader

Comment by dev360 | Hacker News Reader

Long time Django (and occassional rails) dev here.. I've messed with Node from time to time but never really been wowed by the fragmented eco-system around Express (or flask either for that matter).

This looks like a node framework that I'd really enjoy using - first time I see a framework that feels like it fits around ES6. For me personally, having a good ORM and models layer, coupled with migrations have been a deal breaker in choosing a framework, and I'm very happy to see that here.

Is everything written from scratch or are there dependencies? If so, it sounds like its actually quite an opinionated microservice architecture.. Lately I've felt like microservice and microframeworks have gone hand in hand :)

Great job!

View on HN

Most of it is written from scratch. For better or worse, I'm very systems-oriented, meaning I like to understand everything from the ground up and I spend a lot of time reinventing the wheel. (Probably why I studied Biochemistry.)

Very happy with the lessons I learned throughout the process and the end result. Experience with Django and Rails design patterns was a tremendous help.

Yeah, I really feel like its the 'gold standard' in framework design.

Still, I look at things in Django and get angry that they were not MORE opinionated, like Rails. Like, not having a decent REST abstraction out of the box is almost unforgivable in this day and age.

http://lmgtfy.com/?q=django+rest

I think Django's evolutionary decision making has been nothing short of fucking awesome. They've consistently waited until a clear, mature 3rd party winner has emerged for problems before integrating them. When those solutions are integrated, they're battle tested and not going to bite you into the ass.

Django's team is very aware of where their weaknesses are, and they're working on them:

We've been awarded $150,000 to help fund the development of Channels, the initiative to rewrite the core of Django to support (among other things) WebSockets and background tasks, and to integrate key parts of the Django REST Framework request/response code into Django, such as content negotiation. Together, these projects will help considerably improve Django's role of backing rich web experiences as well as native applications.

https://www.djangoproject.com/weblog/2015/dec/11/django-awar...

Rails opinionated approach lead to heavy churn in the 2 -> 3 -> 4 transitions. I don't want to deal with that.

Thats true, but look also at costs over time.. With the fragmented approach, 3rd party frameworks have been suffering big time. How do you normalize between apps that are using multiple different ways to do REST, and how do you handle versioning conflicts? I totally hear what you are saying though.

I found this a difficult line to toe during development. Where do I encourage developers to do whatever they'd like, and where do I enforce some sort of standard? I tried to pick a middle ground. I avoid helper functions where I can. Want to do something before you save the model? Learn ES6 inheritance patterns and write a save() method around the Parent#save.

Will still have to see where people run into the most trouble and go from there. But I would enjoy it if people could pick up Nodal and walk away confident they could build an ES6 app from scratch.

> Like, not having a decent REST abstraction

The community has stepped in here.

Django Rest-framework provides one of the best approaches for creating restful apis that any web framework has to offer. For me, using Django is inseparable from using Django Rest-framework. Its what makes working with Django great.

Nodal by comparison does a lot of great things like Django does, but without the robustness of a rest framework behind it, Nodal seems to have created another good framework but not something new and better.

Django Rest framework was not always great :) .. In fact, nowadays I prefer to use one called Django Restless.

My argument is just that REST is not the type of problem that should warrant having three competing libraries (see comment above).. It has been pretty fundamental to the way you build modern apps ever since SPAs became a big thing.

To think that Rails got many of these things right-ish in version 1.2 which was released in 2007 is pretty damn impressive and speaks volumes about the technical clairvoyance of the ruby/rails community.

I'm previously a Djangonaut too but recently I've been exclusively JS. I spent a few hours playing with this yesterday and I really like it.

It was pleasing (and a little surprising) that everything was almost exactly how I expected it to be. I watched the video, got started and rarely needed to go back to the API docs. It actually feels very light and natural despite the fact that it's already quite fully featured.

I'm beaming. Thank you so much for your comment.

It's been a while for me since I last used Django but i recall it not having a migration framework (besides south).

Language preference aside, I feel as though rails might be a better Django than Django is in almost all areas that you define as deal breakers.

Starting with Django 1.7, migrations have been available in the core package.

Yes thats correct. You had to pick third party libraries for these types of things, which wasn't that big of a deal since the community did a good job of rallying around good libraries.

There's nothing like ruby/rails (I love me some rspec!), but ultimately it came down to lang pref for me, and maybe performance (dev reload cycle mostly). Plus, python has a lot of very interesting stuff in machine learning and science.

Reply on news.ycombinator.com