yoshuawuyts / tiny-guide-to-non-fancy-node

A tiny guide to non fancy, high-value Node.js things

Yosh is …

Calm computing. Working on the Rust programming language at Microsoft. Focused on making async programming reliable and accessible. Also an enthusiast cook, cat dad, and prospective DIY guy. Previously: Berlin, Sydney, Amsterdam. Now in Copenhagen.

Also on: Website, Twitter, YouTube, and Twitch.

Async Rust

• async-std - a port of the Rust stdlib to async Rust
• futures-concurrency - core concurrency extensions for async Rust
• futures-time - time, concurrency, and cancellation extensions for async Rust
• async-broadcast - broadcast channels for async Rust.
• parallel-stream - parallel iteration for async Rust.
• async-task-group - manage groups of async-std tasks as a single unit.

Rust web programming

• http-types - Common types for HTTP operations for async Rust.
• tide - Fast and friendly HTTP server framework for async Rust
• surf - Fast and friendly HTTP client framework for async Rust.
• localghost - Ergonomic Rust bindings to the Web platform.
• async-h1 - HTTP/1.1 parser and encoder for async Rust.
• async-sse - Server-Sent Events parser and encoder for async Rust.
• async-session - Session support with plugabble backends for async Rust.

Support

If you like what I'm working on, please consider supporting my work via GitHub sponsors.

tiny-guide-to-non-fancy-node's Issues

Delet This

How to test for the browser?

Hi, nice guide, thanks for sharing it.
Now, I was wondering, how do you do to test the browser? In the testing section you mention tape, for the unit testing, in node it is pretty straight forward, but I always have problems to test in the browser, so, I want to ask, how do you test the browser? Using some dom mimic library like jsdom or browser-env? or something more complex like a headless browser, e.g. phantomjs? What would be your recomendation?

Thanks again for the guide ;)

Consider referencing maxogden/mississippi

Nice guide! I thought it might be worth expanding the streams paragraph to mention maxogden/mississippi—not as a module you should actually require, but as a great README to reference when working with streams.

Does non fancy vs fancy

In this case let's say, fancy is node 7+ async await pattern.

Would you really prefer to stay inside the callback world instead of having the amazing clean async and await code style. Or would you just call non performant/thread blocking sync code?

It still doesn't need any pre compilation, runs like a beast and the code is clean and understandable.
The only drawback of this is to tell everyone to update to node 7.

I feel like staying in the es3 JavaScript is like saying: I'll style my website with tables, that way I'll be sure everyone can view it correctly instead of trying to learn how to use a flexbox.

This is the main issue i have with the readme. Everyone can have there own tools preference and that is fine. But why deliberately not use new language features?

Boring and stable libraries

I agree with most of this guide except this part sounds too idealistic.

How can libraries that are barely a year old and have gone through multiple major versions with presumably breaking changes already be "boring and stable"?

Not even Node.js itself is boring and stable, it's gone through lots of churn over the few years of its existence, so you're not safe by sticking with the core modules, just relatively safer.

The only way for something to actually be boring and stable is to never make breaking changes, i.e. never release a major version past 1.0. This means that the interface must be frozen and unversioned.

Consider recommending TaskGroup

https://github.com/bevry/taskgroup - example: https://github.com/bevry/taskgroup/wiki/Introduction-&-Usage

Would go well with the error point, as tasks are wrapped in domains by default, so even async throws are caught and can be handled correctly by the task or taskgroup that contains it - as well as using the same API for both serial and parallel, with only concurrency config changing