Find the right developer tools and the companies that use them
Feed
Keep up with the tools you care about
Visit Feed
Stacks
Browse top companies’ stacks
Browse Stacks
Trending
Explore popular and trending tools
Explore Tools
Stackups
Compare tools side-by-side
Compare Tools

See reviews of popular open source and SaaS tools

  • See a personalized feed with the latest reviews and news about your tech stack
  • Share why and how you use tools in front of a community of 250K+ fellow developers
  • Get new product updates, articles, and announcements pushed to you daily/weekly
Check Out the Feed
Eyas Sharaiha
Eyas Sharaiha
Software Engineer at Google · | 19 upvotes · 6480 views
atGoogle
RxJS
Angular 2
TypeScript
#Frontend
#Async
#RXJS
#Angular
#Typescript

One TypeScript / Angular 2 code health recommendation at Google is how to simplify dealing with RxJS Observables. Two common options in Angular are subscribing to an Observable inside of a Component's TypeScript code, versus using something like the AsyncPipe (foo | async) from the template html. We typically recommend the latter for most straightforward use cases (code without side effects, etc.)

I typically review a fair amount of Angular code at work. One thing I typically encourage is using plain Observables in an Angular Component, and using AsyncPipe (foo | async) from the template html to handle subscription, rather than directly subscribing to an observable in a component TS file.

Subscribing in components

Unless you know a subscription you're starting in a component is very finite (e.g. an HTTP request with no retry logic, etc), subscriptions you make in a Component must:

  1. Be closed, stopped, or cancelled when exiting a component (e.g. when navigating away from a page),
  2. Only be opened (subscribed) when a component is actually loaded/visible (i.e. in ngOnInit rather than in a constructor).

AsyncPipe can take care of that for you

Instead of manually implementing component lifecycle hooks, remembering to subscribe and unsubscribe to an Observable, AsyncPipe can do that for you.

I'm sharing a version of this recommendation with some best practices and code samples.

#Typescript #Angular #RXJS #Async #Frontend

See more
Sezgi Uluçam
Sezgi Uluçam
Sr. Software Engineer at StackShare · | 6 upvotes · 14294 views
Flutter
React Native
PhoneGap
Apache Cordova
#NativeApps
#MobileFrameworks
#JavaScript

For a front end dev like me, using a mobile framework for side projects makes more sense than writing a native app. I had used Apache Cordova (formerly PhoneGap) before (because React Native didn't exist yet), and was happy with it. But once React Native came out, it made more sense to go that way instead. It's more efficient and smooth, since it doesn't have the simulation overhead, and has more access to hardware features. It feels cleaner since you don't need to deal with #WebView, using native UI widgets directly. I also considered Flutter . It looks promising, but is relatively new to the game, and React Native seems more stable for now.

MobileFrameworks #JavaScript NativeApps

See more
Go
Lua
OpenResty
nginx
Logstash
Prometheus

At Kong while building an internal tool, we struggled to route metrics to Prometheus and logs to Logstash without incurring too much latency in our metrics collection.

We replaced nginx with OpenResty on the edge of our tool which allowed us to use the lua-nginx-module to run Lua code that captures metrics and records telemetry data during every request’s log phase. Our code then pushes the metrics to a local aggregator process (written in Go) which in turn exposes them in Prometheus Exposition Format for consumption by Prometheus. This solution reduced the number of components we needed to maintain and is fast thanks to NGINX and LuaJIT.

See more
Dmitry Mukhin
Dmitry Mukhin
at Uploadcare · | 21 upvotes · 14681 views
atUploadcare
PostCSS
Preact
Ember.js
React
Python
Django

Simple controls over complex technologies, as we put it, wouldn't be possible without neat UIs for our user areas including start page, dashboard, settings, and docs.

Initially, there was Django. Back in 2011, considering our Python-centric approach, that was the best choice. Later, we realized we needed to iterate on our website more quickly. And this led us to detaching Django from our front end. That was when we decided to build an SPA.

For building user interfaces, we're currently using React as it provided the fastest rendering back when we were building our toolkit. It’s worth mentioning Uploadcare is not a front-end-focused SPA: we aren’t running at high levels of complexity. If it were, we’d go with Ember.js.

However, there's a chance we will shift to the faster Preact, with its motto of using as little code as possible, and because it makes more use of browser APIs. One of our future tasks for our front end is to configure our Webpack bundler to split up the code for different site sections. For styles, we use PostCSS along with its plugins such as cssnano which minifies all the code.

All that allows us to provide a great user experience and quickly implement changes where they are needed with as little code as possible.

See more
Justin Dorfman
Justin Dorfman
Developer Evangelist at StackShare · | 8 upvotes · 6197 views
Insomnia REST Client
Node.js
GraphQL
#CURL

Today I was helping a friend with a GraphQL query (pagination). At first, I was just going to hack at a Node.js script but she told me to download the Insomnia REST Client and I have to say, it was a great experience. I might have to keep it installed for future use.

Besides #cURL what other REST client's should I try?

See more

Show your company's entire software stack to thousands of engineers

  • Attract developers by explaining what you use and why
  • Easily reference your software stack by sharing it on job hiring sites
  • Invite your engineering team to contribute to your stack page
Explore Top Stacks

All the best open source, SaaS, and developer tools in one place

  • See what other developers are using
  • Discover new tools submitted by the community
  • Learn why developers like the tools they use
See What's Trending Now

Side-by-side comparisons
of the top options

  • See side by side comparisons of software tools
  • Select and create your own Stackups
  • Decide which tools & services are best for you
Compare Tools

Learn how top startups are scaling their tech stacks

  • Learn how some of the best software products in the world were built
  • Understand how and why companies are using specific technologies
  • Get insight into the technical challenges companies face at scale
Explore Stack Stories

Want to advertise with us?

StackShare In The Press


What is StackShare?
StackShare provides online software for displaying and sharing your technology stack, which is made up of the software that you use. We're an online community that features comparisons, ratings, reviews, recommendations, and discussions of the best software tools and software infrastructure services.