Show HN: Nodal. Next-Generation Node.js Server and Framework

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.

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.

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.

JavaScript is becoming the web darling (or it already is?), whether we like it or not. And with some nice syntactic improvements ES6 brings, I don't mind.

Lately rails got their socket support, and python3 has been getting better support through async, but in both those languages, I've long felt its been pretty experimental, and there simply hasnt been a performant option available that has a good opinionated framework.

Nodejs has performance going for it at least if you look at the language benchmarks, and now with ES6, it feels like the language is finally starting to shape up.

out of curiosity, which language + library/framework pairs do you think is a better tool than javascript + nodejs when evaluated along each of your 3 metrics?

I moved from python + flask to nodejs a while ago, I still thing nodejs is better than python + flask, but I'm trying to move away from javascript on the backend.

I think that this is specially appealing for people that are building offline enabled clients, which end up having to handle more business logic than usual for client-side code.

One major advantage I can see is if you're a full stack dev. You don't have a switch languages when you're building the backend and the front end. Some people may not see this as an advantage, but personally it takes some time for my brain to switch to javascript for the front end when I've been using either java, python, or ruby for the backend.

For example I'm taking some front end javascript I've been working on and putting it on the server (using another new node framework based on Laravel that so far I really like: http://adonisjs.com ) and it would definitely perform better if I rewrote it in Go or Elixir - but even if I could figure out how to do that if the thing takes off I could never find anyone to help me with it.

With JS though it should perform reasonably well (node is supposedly pretty fast where it counts, nonblocking and all that) and I could hire a danged high school kid to give me a hand with it if it somehow succeeds. I imagine a company like Walmart was thinking along those same lines when it chose Node.

The reason why JS + node is popular is becasue it's pretty good at each of the metrics you mentioned. Even though it's not best in class at any one of those, it is well balanced for many tasks. Many other technologies are either too slow, too low level, too hard to scale, or too cumbersome to work with.

- Node's package manager npm is fantastic, and (imo) gets package management more right than 90% of other package managers

- There are 1000s of high quality actively maintained modules on npm to get you started on things (and 1000s of garbage ones, so you have to be careful)

- The "holy grail" web app architecture (server rendering of frontend JS components coupled with client side rendering in a SPA) is only possible by running some JS on the server

- Sharing JS UI components between the backend and frontend is a huge DX and productivity win

- Another huge maintenance win is using the same language across the whole stack (frontend, backend and devops/automation)

- With ES6, JS is slowly turning into a pretty cute language, check it out :)

- A nice level of cross-pollination between JS and those geniuses in the ClojureScript community is bringing some really nice functional programming approaches and projects to Node/JS

- You can use Node and JS to compile to both native desktop apps and native mobile apps. Having a centralised UI library of JS components that you can leverage for your desktop app, mobile app, frontend SPA and backend static rendering sounds pretty good to me!

If you structure your ops to be reorderable and composable you can get nice stuff like multi user editing, arbitrary undo, multi data centre synchronization, etc.

See the google docs papers for more details.

1) Bad concurrency model -- callbacks, promises and futures are in general inferior abstraction model compared to green threads, actors, regular threads. Performance-wise it might do well in some scenarios but you are forced to use a more complicated abstraction to get that performance It is not worth it. In general it is appealing because it looks simple in small demos, as applications grow it becomes a mess.

2) npm modules are easy to use and that's great. Good model (well maybe except for deep nesting which breaks based on max path in say Windows, but I hear they are fixing that). The problems I found was that a lot of modules were of low quality. Code half-finished, buggy, developer moved on to something else, etc. Somehow it seems more so than say in the Python community.

3) Javascript is not the best language. There is a reason there is a "Javascript: The Good Parts" book. Because there are lot of crazy decisions made in it originally and a lot of bad "parts". If there was a choice between FORTRAN, Cobol and Javascript. I would pick Javascript hands down, but there are other languages out there today.

However. If all you know is Javascript and you want to write a small demo, then go for it. It will be the least friction.

So with all this complaining and whining, how about some constructive stuff. What language / frameworks might be more interesting / better.

1) Go : good concurrency model, supported by a large community, good performance. Lots of big companies use it.

2) Elixir : new kid on the block, fun, one of the friendliest communities. Probably best concurrency model -- actors. It uses Erlang's VM, so that part is rock solid, battle tested for many years. But not as many libraries. But can use existing Erlang libraries from it. Also best for reliability and fault-tolerance.

3) Python : easy to learn, lots of libraries, lots of material how to use it. This is my go-to language to get stuff done quickly. Try Python 3 if you start from scratch.

4) Clojure, Scala, Java: run on JVM. Battle tested, probably lots of libraries. Personally not as familiar with it, most enterprise and big sites out there run on the JVM currently.

All of my recent projects have been isomorphic react apps. I build my app like it were a fully client-side single page web app, but I get server rendering when there's a new http request. Once the page has rendered, the web app takes over and uses history pushState. There are very few pieces of code that aren't used in both places. Once you get the hang of it, you very naturally create mockable interfaces that can be swapped depending on environment.

In my opinion, this is pretty much the only category that makes JavaScript "Best-in-class"; It's the easiest language to build isomorphic web apps.

But if you go back to the origin story of Node, it's all about libev (though it now uses libuv for the same purpose) and that pervasively-asynchronous mindset. JavaScript was chosen as the developer interface because it met the need to support that asynchronous philosophy. The result is that everything in the Node world is asynchronous and asynchronous is the path of least resistance for the developer. Other platforms that weren't conceived with this mindset often force developers to fight to be asynchronous.

> It seems like whether you're aiming for ease/speed of prototyping, pure performance, a good concurrency model...

It's a mistake to look at JavaScript as a fit for all of this. Instead, you should consider how the Node platform fills the need. For easy of prototyping, it's not JavaScript that makes Node excel, it's npm. The only package management system I've found that I prefer to npm is Rust's Cargo. And npm is still well ahead of Cargo in the richness of the package ecosystem. For pure performance, you can always write a native Node addon [2]. And, as mentioned, while JavaScript isn't concurrent at all, the Node platform provides the concurrency model in a way that has proven to be scalable but without most of the pain that comes with writing concurrent code. Writing concurrent code is hard...that's not news. The Node framework make writing concurrent code significantly easier by creating abstractions that hide the the fact that code is concurrent.

I know it's bizarre to look at it this way, since you would be writing most of your application logic in JavaScript, but try to look at it as an implementation detail and consider the advantages of the Node platform and the ecosystem that surrounds it. When you take this perspective, Node becomes a lot more attractive than the JavaScript language is on its own.

[1] https://luvit.io/

[2] https://nodejs.org/api/addons.html

I could be way off here (and I probably am) but shouldn't frameworks abstain from being too opinionated about the particular technologies that you use? The database (or type of db) you choose seems like something that should be based on what your application's requirements dictate not what your framework prefers right?

NoSQL has its place, but it's usually not the best choice. Any "comprehensive" web framework should cater to the needs of RDBMS users at a minimum, with support for NoSQL as a plus.

What are the benefits of "import" over "require"?

1. POJOs are ugly and you must revert back to using Object.create() for inheritance, breaking the design pattern of using ES6's class syntax.

2. PascalCase class <-> camelCase instance <-> underscore_filename <-> underscore_tablename is a standard borrowed from Rails and easily managed through the npm inflect module (i).

3. It's just a shortcut. You can use normal CommonJS require(), you'll just have to resolve the relative path yourself.

4. Thanks! :)

5. Models can exist without database connections and with manually defined schemas. If you check through the commit history, I used to keep database and model completely separate but there was way too much code reuse / smell (passing in a db as a parameter on every function call).

6. The alternative is setting properties with ClassName.prototype.value = 'xyz'; or ClassName.value = 'abc'; Static methods provide an easy to read + concise way to do this for you (and take care of additional functionality). Also borrowed from Rails.

7. Chose that pattern because it is very explicit / ordered. How do I determine what order the routes are hit when I specify them per Controller? And if I define them on the Controller, that means I need to load all Controllers globally on Application start.

8. I'm happy with how clean the code is now. :)

promises are rad, and I know I can just use Bluebird's promisifyAll to wrap your code. But still, it would be nice if I didn't have to muck around with that and async methods called without a callback returned a promise by default.

middleware is rad, it lets me abstract out pre-processing that happens on (say) every POST route to validate parameters. It doesn't look really feasible to do that with this system. I'd basically just have to bake all that into the post() method, which isn't super-modular and is probably harder to write unit tests for.

can't say that I'm wild about regex routes by default. I dig stuff like 'items/:itemId' with named parameters in a microsyntax. Makes life a lot easier.

For those looking for an "enterprise" alternative to Express, give Hapi a try! It's very mature, has tons of extension modules (as pfooti mentions), and basically can do mostly everything you need without your needing to write much glue code.

Also, if you use typescript, it has a .d.ts file at Definitely Typed. (I wrote it)

http://webaim.org/resources/contrastchecker/?fcolor=00E1FF&b...

I'm really flattered you found things you thought were interesting! Would you care to share?

This is the major reason why I have learned to be cautious with getting wowed by the apparent simplicity of micro frameworks.

At the very minimum, I want a framework to have an opinionated model layer with migration support, and chances are you will get trickle down benefits from frameworks that have opinionated M layer..

Look at djangos form abstraction for instance. Or the way validation is handled in Django models, which in turn opens up for the possibility of creating a neat REST abstraction. These are the types of abstractions that you end up writing yourself or not writing at all when you go the 'light framework' route, but they are almost always handy and will save you time.

Sometimes you want something like Rails or Django. Then express and similar "a la carte" solutions won't help you and you'll end up re-inventing frameworks and re-implementing the same old bugs and mistakes.

Sometimes you just want a small single-purpose server. Then Node and NPM shine and big frameworks seem like unwieldy behemoths in comparison.

Personally I'd say Node isn't a good choice for the former and you'd be better off with something powered by Ruby, Python or PHP (i.e. Rails, Django etc). And I say that as someone who's been almost exclusively using JavaScript for the past couple of years.

It may be a great framework, but that strikes me as an odd point to make about the project.

Do you care to elaborate further?