Avatar of Nick Parsons

Nick Parsons

DeveloperEvangelist at Stream

Decision at Stream about Go, Stream, Python, Yarn, Babel, Node.js, ES6, JavaScript, Languages, FrameworksFullStack

Avatar of nparsons08
DeveloperEvangelist at Stream ·

Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.

We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)

We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.

Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.

#FrameworksFullStack #Languages

29 upvotes·26.3K views

Decision at Stream about Electron, CrossPlatformDesktopDevelopment

Avatar of nparsons08
DeveloperEvangelist at Stream ·

We wanted to experiment with building an Electron app with downloads for every Linux distro, macOS, and Windows, in addition to the web. Fundamentally, this seemed pretty easy: we write code, wrap it in an Electron shell, and release to our desired operating system… It turns out we were wrong.

Electron, though powerful, turned out to be a bigger beast than we had anticipated. Building to different distros was especially hard, even with electron-builder (granted, we had the bad luck of needing to patch electron-builder (and that bug has since been fixed), but that only accounted for some of the pain points we hit). The macOS menu bar had to be just right for the macOS store to accept our app, and performing small tasks with the Electron API, like opening a link in an external browser, turned out to be pretty difficult.

Despite the difficulties, our team moved forward with some custom tooling (all visible and open-sourced on Github) and we released not only to all of our release targets but to the web, too.


25 upvotes·1.8K views

Decision at Stream about Stream

Avatar of nparsons08
DeveloperEvangelist at Stream ·

Here at Stream, we recently build a powerful CLI to support our Feeds & Chat products. In doing so, we learned a lot about best practices when crafting a positive developer experience in the command line. Quick findings:

  • JavaScript is more powerful than you think. Tap into the massive ecosystem and a large number of open-source projects.

  • For inspiration, look at the functionality that Zeit and Heroku provide within their CLI to make for an awesome developer command line “experience”.

  • If your API/CLI requires data persistence, store that data in a cache directory that is specific to your CLI. Load this using a util file as we do at Stream. Also, note that the fs-extra package will come in handy for this type of thing (even though support is built into Oclif).

  • Oclif is the way to go, especially if you’re building a large CLI, as opposed to a single-command CLI. If you’re building a single-command CLI you can still use Oclif, just make sure to specify that it’s a single-command API when you’re scaffolding your CLI.

  • Don’t want to use a framework? That’s okay! The package minimist provides argument parsing in the command line and can easily be used within your project.

  • Use prompts, when you can, with enquirer or another package of your choosing. Users should be walked through the requirements of the command and asked for the data the command needs in order to execute properly. Note that this should never be required (e.g. let the user bypass the prompt if they pass the correct arguments).

  • Use colors when possible to make your CLI a little easier on the eye. Chalk serves as a great tool for this. If you have response data that is well enough structured, don’t just print it out to the user (unless that’s what they specify). Instead, drop it in a table using

  • Always allow the user to specify the output type (e.g. JSON), but default to a message that is human-readable.

  • Keep it fast! For time-consuming tasks such as file uploads or commands that require multiple API calls, we recommend showing a loading indicator to let the user know that work is being done in the background. If you’re looking for a package on npm, we recommend checking out ora.

The full blog post can be found here: https://medium.com/@nparsons08/crafting-a-command-line-experience-that-developers-love-68657b20c28d

4 upvotes·1.6K views

Decision at Stream about

Avatar of nparsons08
DeveloperEvangelist at Stream ·

I had a pretty good time writing a React Native Chat tutorial. I used some great tools, some of which you likely know and others that you probably are not aware of. Here's my decision:

The full tutorial can be found here: https://medium.com/@nparsons08/react-native-chat-with-chuck-norris-dd5721523742

2 upvotes·125 views