Console
Developer tools reviews
Each week Console reviews the best tools for developers.
✦ Disclosure: All reviews are editorially independent and partners must meet our selection criteria. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
Category reviews
Interesting Tools by email
Our free weekly newsletter picks out the 2-3 most interesting tools. See the latest email.
Join 14k+ developers
What we like: Define rules and automations in code based on conditions for approvals, assignment, merges, rebasing, reviews, queueing and prioritization. Can examine attributes like task list status, PR dependencies, Dependabot, Snyk and other tool integrations. Engine is open source.
What we don't like: GitHub only. Specifying PR dependencies does not work across repos.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Code samples can run locally in the browser (using WebAssembly). Can be embedded into a web page using an iFrame or web component. Enable editor to allow the user to modify and run the code. Sandboxed and runs in a terminal emulator.
What we don't like: Limited by language runtimes available in WebAssembly Package Manager - Python, JS, SQL, C, C++. Best for simple code that uses stdin / stdout.
What we like: Lots of plugins for sources e.g. AWS S3, Apache, StatsD, stdin; transforms e.g. aggregate, filter, log to metric; sinks e.g. Cloudwatch, Prometheus, Elasticsearch. Makes it easy to create a consistent pipeline even as sources and sinks change - no lockin. Can run as a single agent, sidecar or as an aggregator cluster for more throughput. Open source.
What we don't like: Transforms performed using the custom Vector Remap Language, which is another syntax to learn (but does compile to Rust = safety + performance).
What we like: Manage your packages across all repos from a single service (RPM, Deb, RubyGem, PyPI, NPM). Web UI or CLI to push new packages. Create private repos for internal packages. Auto-generates install scripts for users. Integration with CI to easily push packages on build.
What we don't like: Quick installer instructions and package inspection (view files, dependencies, etc) not available for all package types. Would like to see support for container repos.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Project-based and sandboxed, which makes it safer to use it to try third-party projects. Config is code (Starlark) - no arbitrary flags, env vars, etc, so the result is much more predictable. Inputs/outputs are content addressed, hashed and cached (or built from source) which then makes them reproducible.
What we don't like: Currently a proof of concept, only works on Linux (macOS soon). Defining the full dependency tree can be tedious, but that is the whole point of sandboxing and ensuring reproducible builds.
What we like: Quickly show possible performance problems in your HTML <head> such as blocking JS, redundant calls, third-party stylesheets. Either drop in a CSS stylesheet or run the JS snippet for any page using browser devtools.
What we don't like: Prone to some false positives, e.g. non-blocking non-print stylesheets, injected JS, whether the third-party JS is truly non-blocking. Unknown license.
What we like: Use GraphQL to query resources. Queries run against a cached database which you can scale yourself, avoiding AWS limits. Consistent interface across products - avoid complex JOINs. Query historical state because data is versioned. Bundled UI with autocompletion and schema explorer.
What we don't like: Currently only supports AWS. Deployment is currently manual (or via Docker). Docs are still quite limited.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Quickly search and filter system and user units. State view shows service metadata plus recent logs. Shortcuts for filtering by state and reloading. Prompts to run relevant commands.
What we don't like: Requires fzf, which must be installed manually. Assumes you know what you’re doing, but since it’s Linux-only, you probably do.
What we like: Significantly speed up common git tasks with shortcuts. Improved version control view with show/hide diff, easily stage individual files or multi-select changes. Stage chunks of changes. Forge mode provides extra context from GitHub e.g. issues, PRs.
What we don't like: Forge mode slows down status view initial load. Doesn’t yet support the more advanced features from Magit (advanced diff, bisect, patch).
What we like: Displays real-time stats as tests are executed, both on the CLI and via a web UI. Reports latency, req/s, errors, read/writes. Includes latency histogram and percentiles. Supports all HTTP verbs including reading in POST data from a file. Dockerfile provided.
What we don't like: Histogram charts disappear and web UI stops serving on test completion.
What we like: Runs a full version of SQLite entirely in the browser. Can load DB files from a URL or a file. Can optionally sync with GitHub to save data and queries in plain text. Easy to share via a link. There is no server. Open source.
What we don't like: No code completion. No error handling UI (check the browser console).
What we like: Implements automated delivery from Git to k8s. “giterminism” concept provides reproducibility without external config dependencies - everything is based on the git repo. Handles Docker image builds, k8s rollout and cleanup. Can be embedded in existing CI/CD pipelines. Generates and manages Helm templates.
What we don't like: Needs expanded guides for languages - basics are covered but missing more detailed real-world examples. Assumes you’re running on k8s.
What we like: Automate tedious incident handling workflows e.g. create new Slack room, status page update, create Zoom bridge. Inventory catalog assigns teams and aggregates useful tools (e.g. PagerDuty on call, Datadog dashboard, last GitHub event) for quick lookup during incidents. Auto-generate timelines based on chat logs, events, actions to make retrospectives easier.
What we don't like: Small number of integrations e.g. assumes using Slack for chat, JIRA for tickets, Zoom/Meet for conferencing.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Record and debug user sessions with full devtool capture (JS errors, network, perf, state). Sanitize data before it is captured through generic global rules or HTML attributes. Can un-minify JS with source maps. Plugins to capture API requests e.g. GraphQL and correlate with backend monitoring (Datadog, New Relic, Cloudwatch, etc).
What we don't like: Limited documentation for scalability and reliability - you must manage multiple components e.g. Redis, PostgreSQL (a fully managed cloud version is available). Data exporter only available in enterprise version.
What we like: Work from a CLI, interactive TUI or web UI. Doesn’t pollute your repo (everything lives in .git) and interactions are like normal Git (add, push, pull, etc). Issues can live alongside the code repo they belong to. Can bridge with GitHub, GitLab and JIRA so you can use git-bug and others can stick with a centralized server.
What we don't like: Web UI is currently read-only. Does not support media file attachments. Not a stable release yet, but still worth playing with.
What we like: Can be used as a database server or as a library. Acts as a k/v store or can be queried using SQL. Storage agnostic - can even be S3. Built-in Prometheus endpoint. Can disable synchronous indexing to increase performance. Supports PostgreSQL wire protocol. Interesting use case as a secondary database for cryptographic verification of the primary.
What we don't like: Only Go SDK is fully developed - others still in progress. No replication or hot backup support yet.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Supports input from a file, URL or stdin so it can be piped to grep and properly searched. Allows the full path to be revealed. Colorizes output. Easily diff sets of JSON. ungron reverses the conversion, so you can pipe grep results back to JSON. Cross-platform binaries available for Windows, Linux and Mac.
What we don't like: You could just use jq which has more features, but it assumes you know more about your JSON data structure. gron is deliberately simple and grep is well known.
What we like: Allows you to move between stacks of commits without using branches. `git move` is implemented in-memory so is faster than `git rebase`, which works on-disk. Interactive `git undo` command helps fix commits, merges, rebases, checkouts and branches. Smartlog command visualizes work without branches (unlike `git log --graph`).
What we don't like: No release binaries - must be installed (and compiled) with Rust’s cargo. Not designed to handle untracked files.
What we like: Lots of desktop and mobile browser versions, including very old devices and new betas. Can write tests in open source Selenium or Cypress frameworks. Tests can be automatically compared against previous runs. Integrates into CI/CD to detect regressions. Geotarget features can test localization e.g. currencies, time zone changes etc.
What we don't like: Mobile tests are executed on emulators (real device support currently in beta). No support for testing on Linux.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Displays line numbers. Side by side view. Can be used independently from the terminal, but configured through git means it supports all git features outputting code. Highly configurable theming and output options e.g. colors, line number styles. Cross platform and OS packages for multiple systems.
What we don't like: Colorized output does not follow the current terminal theme - must be independently configured.
What we like: Runs the commands from your Procfile or Docker Compose config e.g. running separate commands to launch your project’s UI and API. Aggregates logs into a single, colorized terminal output. Local web GUI allows log toggle, search & filtering, manage spawned processes and other resources e.g. Docker storage. CLI can control processes, query logs and daemonize.
What we don't like: Weird, custom open source license. Web docs could do with expanding - CLI has a useful builtin help command though. No OS packages - binaries for Linux and macOS only.
What we like: Local evaluation of feature toggles avoids network latency. SDKs for all major languages. Proxy module means it can work even for single page apps. Support for gradual rollout and user segmentation strategies e.g. by user profile fields. Tech debt dashboard tracks use of feature flags and warns if they are unused.
What we don't like: Unclear how to deploy in a high availability configuration. Limited usage stats (evaluations over the last minute and hour).
What we like: Highlights dependencies and related code structure. Code maps auto-update with each commit - map diffs posted into GitHub PRs. Can build step-by-step tours for onboarding new devs into the codebase. Auto heat maps by latest activity, creation date or commit count.
What we don't like: Requires GitHub. Currently only supports dependency resolution for 4 languages (Python, JS, Java, Go).
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Uses terminal theme colors. Layout makes it easy to read. Tree option shows parent and child processes. Can look into Docker to reveal container name & commands. Watch mode like top. Columns can be configured at run time or in a config file. Can show ports processes are listening on. Cross-platform support.
What we don't like: macOS and Windows support is experimental (worked fine in our tests). No pager on Windows. Search is case sensitive.
What we like: Ranking algorithm means it usually guesses which path you mean so you can navigate common long paths without typing them all out. Multi-platform options for installing. Includes an fzf-powered interactive mode. Integrations available for Emacs, Ranger, Neovim. Zsh autocomplete available.
What we don't like: Years of muscle memory using cd means you probably want to alias it to zoxide. Renamed paths can confuse the history - need to edit the DB to update them.
What we like: Auto connects to Brave, Firefox, Chrome, terminal, Android, Edge or acts as a generic proxy. Inspect all HTTP requests. Create rules (match on regex, URL, host, JSON, headers), intercept and rewrite - pause requests to manually edit them, time out, transform, forward to different hosts or return fixed responses. Open source.
What we don't like: No support for Safari, iOS or Docker (on the roadmap). No free trial for pro features like import/export HAR, more advanced rules, mock API templates, etc.
What we like: Quickly examine or search the full contents of any container - files, layers, Dockerfile. Visual diff of file system, image metadata, and Dockerfile between container versions makes it easy to see what has changed. Examine popular public images and connect private registries (Docker Hub, GCR, AWS ECR).
What we don't like: Does not yet support GitHub Container Registry. Would like to see saved searches or suggested alerts to monitor for common issues with new versions.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Methods for enforcement at request and field level. Relations allow hierarchical access control. Data filtering converts policy expressions into DB query plans to efficiently retrieve only the data that matches the filter. Generic policy language is evaluated locally by language-SDKs (NodeJS, Java, Python, Ruby, Go, Rust).
What we don't like: Provides the hooks for framework / ORE integrations but you still need to build them. Currently focused on backend auth - anything frontend you need to figure out yourself.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Helps validate files, APIs and configs e.g. k8s files. Definitions start broad e.g. types then narrow down e.g. values, so it is easy to get started, but still supports specific validations. Language is a JSON superset. Supports comments (unlike JSON!). Can extract existing definitions from Go and Protobufs.
What we don't like: Documentation explains the concepts well but is missing a “from zero” getting started tutorial (the k8s tutorial is good, though).
What we like: Stores access credentials in native OS storage e.g. Windows Credential Vault, macOS Keychain. Easy to switch between credentials e.g. AWS IAM, Azure User. Session credentials are temporary, minimizing risk of leaks and making them easy to rotate. Open source.
What we don't like: Only supports AWS and Azure. No U2F support. Supports some federated identity providers e.g. Okta, GSuite, AWS SSO, but only to AWS and Azure.
What we like: Supports all API protocols (REST, GraphQL, TCP, gRPC). Handles API versioning and deprecation. Hot-reload without dropping requests. Minimal dependencies (Redis for distributed rate limits and tokens). Drop-in products for developer portal + docs, analytics, social auth, management dashboard. Open source or cloud options.
What we don't like: Architecture gets complex once you start to add the extra components, which are also not open source. Historical performance issues in older versions due to overhead of some features enabled by default (reportedly now fixed).
What we like: Catches common issues which can either be fixed as part of a PR and/or blocked by CI. Can open “Autofix” PRs for code issues as well as linting errors. Examines docs and code coverage and reports metrics for both. Image badges for readme files. Can configure analysis via a config file in the repo or via the UI. Self-hosted version available.
What we don't like: Doesn’t explain “why?” you should make the suggested changes or follow its rules - good to fix errors but better to understand how to avoid them in the future. Autofix can’t solve everything (yet?).
What we like: Abstracts auth and storage so you can use P2P decentralized tech like IPFS without worrying about the underlying protocol. Web Native File System works across platforms and has a POSIX-style interface. Supports storage/execution of WebAssembly modules which are then available on every platform. Open source.
What we don't like: Auth tokens live in browser storage so you could lose access if you clear the data. Risky to rely on such an early new backend tech that is not yet standardized and built by a new startup (everything is open source so you can run it yourself).
What we like: Web demo allows you to query any public repo (+ GitHub issues), or download the CLI. Can do complex queries like commits by email domain, most frequently changed files, filter by branch. Supports querying GitHub API e.g. query stars, repo language stats, issues/PRs. Outputs as an ASCII table, JSON, CSV or SQLite file for other tools to query the results.
What we don't like: Queries can be slow - several seconds. Read-only queries. Only integrated with GitHub Issues (for now).
What we like: Code structure search on syntax e.g. function arguments, multi-line blocks, JSON structures. Can scope to repos (public / private), commit diffs/dates, languages. Option for self-hosted indexer for private code. Browser & IDE extensions for quick search and overlay on top of existing tools e.g. GitHub/GitLab PRs. CLI or web UI (with dark mode).
What we don't like: No custom theme support for the web UI. Can’t search issue trackers.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Build & execute HTTP, GraphQL & WebSocket requests. Syntax highlighted response parsing. Generate code to execute requests via curl, Go, Python, and other languages. Save config to local storage or GitHub Gist. Also available as a Chrome or Firefox extension. CLI in beta. Open source.
What we don't like: Can’t automate a chain of requests - have to manually set up each request. Can’t support cookie headers due to browser security limitations.
What we like: Quickly build interfaces to existing databases. Proxies queries to the data source so results are not stored. Easy form construction with validation and data binding. Can use JS to write data transformations (both read and write). If the GUI concepts are too restrictive, you can always fall back to JS to customize widgets. Open source so you can host it all inside your own network.
What we don't like: No user collaboration in the UI editor so others editing the same project can overwrite each other. Your UI config is stored inside Appsmith’s database (MongoDB) so you can’t use version control (can be exported to JSON).
What we like: Supports staging / non-staging environments. Datasources can be databases like MySQL and Postgres or APIs like Stripe, S3 or GraphQL. Can query all sources with SQL even if they aren’t databases. Everything is a JS object you can manipulate. You can build your own custom React components. Can configure your own Redis/Memcached cache.
What we don't like: Not open source, but there is a self-hosted option. Ability to sync to Git is enterprise-only. Doesn’t support complex logic e.g. multiple API calls.
Snyk Open Source
Snyk Open Source
Dependency security monitoring for open source.
What we like: Easy to see security status for everything. Scans full dependency tree revealing your actual security posture e.g. vulns in dependency dependencies. Relative severity scoring helps understand how relevant issues are. Inspects containers & OS packages as well as code. Separates dev dependencies from prod. Multiple options for fixes e.g. via CLI, not just PRs.
What we don't like: Showing vulnerabilities in dependency dependencies is interesting, but what are you going to do about them? CLI to apply fixes still in beta (Python only).
Security Scorecard, from OSSF
Security Scorecard, from OSSF
Security health metrics for open source.
What we like: Assessment criteria are objective, consistent and documented so OSS projects can start to adopt them. Makes it easy to assess the security posture of the projects you rely on. CLI output is clear why a check fails. Can scan a GitHub repo or infer it from npm, pypi or rubygem package names. JSON or CSV output means results can be scripted.
What we don't like: Some assessment criteria (such as looking for commits from >1 GitHub organizations) may be onerous for small, one-person projects. No easy way to integrate into CI/CD yet (on the roadmap).
What we like: Components to easily add live presence (live cursors, chat and reactions). Abstracts away the backend implementation challenges - networking, performance, presence detection, multi-browser support. Vendored as React / Node packages. Auth hooks to validate user permissions. Examples for raw JS, Next.js, Nuxt.js and React + Firebase.
What we don't like: Assumes you’re building with web technologies i.e. JS. No mobile support. Still requires implementing authentication. Classic build vs buy - is it a good use of your time to try and build this?
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: SDKs for React, JS, iOS and Android to build video / audio without needing to understand WebRTC. Selective Forwarding Unit server makes it easy to scale from P2P to supporting large numbers of participants. Server scales horizontally using Redis as the backend. Automatically supports different connection types (UDP, TCP, TURN) and simulcasting.
What we don't like: Still need to set up SSL + load balancers. Using a server component defeats the idea of P2P. Your code still needs to deal with issuing access tokens to each participant. Simulcasting only works in the browser/JS SDK.
What we like: Multiple browser panes side-by-side to test various sizes. Inspect element works across panes simultaneously. Scroll sync helps comparison. Built on Chrome so devtools available. Shows Web Vitals scores. Can trigger media features e.g. prefers-color-scheme, reduced-motion. Debug tools like a11y, CSS injection, disable images, mobile reachability.
What we don't like: Signup/license key process is a bit fiddly. Quite CPU intensive. You need a very big screen to see all the windows properly.
What we like: Built for JS applications to allow read/write to properties whilst avoiding conflicts. Maintains a history of all changes. Network-agnostic but includes a sync protocol for send/receive messages. Custom types for conflict free counters, collaborative text editing and tables. Follows the idea of functional reactive programming.
What we don't like: Documents are not actually immutable by default - you just code as if they are. Enforcing this can be turned on but has a major performance hit. Implementation is only in JS but versions in Rust, Swift, Python in various stages of development.
What we like: Quick start a P2P encrypted call + screen sharing session. Quality settings go up to 5k to make code crisp and easy to read, unlike generic conferencing services. Easy to take control to type, send through keyboard shortcuts, highlight areas of the screen. Live call debug info to see any connection problems. The “ship it” stamp effect is fun.
What we don't like: Really needs a high quality connection otherwise you can’t reach the higher resolutions and the mouse/keyboard sharing is laggy. macOS only - Linux client on the roadmap for 2021.
What we like: Autocomplete is accurate - speeds up work on a line-by-line basis, just like GMail/Google Docs. Understands file context - imports, variable names, etc. Using comments to describe what you want to do then reviewing suggestions is like doing a web search. Time saver for simple, common, but annoying tasks e.g. regexes, test skeletons.
What we don't like: Not clear if it’s thinking or not - sometimes you wait for nothing to happen. Licensing questions remain unanswered - is the code a derivative of copyrighted material? Doesn’t understand project context.
Waypoint, from Hashicorp
Waypoint, from Hashicorp
Build, deploy, and release across platforms.
What we like: Single command to get your code into production. Can track Git repos to auto-deploy. Integrates with AWS, Azure, Google to upload artifacts, configure LBs, DNS, env vars, etc. Stream logs and execute remote commands. Preview URLs for staging. Web dashboard summarizes deploy status. Extensible hooks via plugins.
What we don't like: Assumes your app is containerized. Need to run / maintain your own Waypoint server - still early so not entirely prod-ready. Preview URLs are public so you must set up authorization or disable them (self-hosting URL service is an option, but complex).
What we like: Built-in tabs, panes, sessions, resizing, scrollback. Shows (customizable) keybindings to help discovery. “New pane” algorithmically placed in the most optimized position (or use manual splits). Can configure layouts in yaml then auto start them. Single compiled binary. Has a built-in file manager (a clone of ranger). WASM-based plugin system.
What we don't like: Colors not inherited from existing shell config. Docs are still very limited. Some core shortcuts used by other tools e.g. Ctrl + r in bash (use Zellij lock mode to pass these through). Slightly laggy over remote connections (compared to tmux).
What we like: Really simple way to execute HTTP commands but can also send more complex requests e.g. headers, file uploads, cookies, JSON. Can write commands in plain text, JS, or define variables in templates. Prettified and syntax-highlighted response parsing. Can save to local browser storage (GitHub and others on roadmap). Open source codebase.
What we don't like: Requests run through a proxy rather than your browser (due to CORS), but localhost URLs are routed directly. No support for OAuth APIs.
What we like: Single compiled binary. No bootstrap requirements - supports many platforms. Can query password manager for secrets and supports encrypted files. Configs can be templated for differences across environments. Can run scripts, including run-once (ideal for cloud IDEs or ephemeral environments). File edit flow similar to git (which is used for versioning).
What we don't like: You can edit files directly but using the edit flow ensures changes/conflicts are handled properly, which may require retraining muscle memory. Doesn’t handle git subdirectories e.g. Oh My Zsh particularly well (better to use a script to install outside of chezmoi).
What we like: Lookup IP details such as ASN, location, hostname, abuse contact, tor/VPN/hosting IP categorization. Cross-platform binaries. Colored output. Bulk summarize IPs from a file (or piped in). Bash, zsh, fish auto-completion. SDKs available for major languages.
What we don't like: Responses not cached. Available via Homebrew on Mac but not Linux or Windows package managers. No man pages.
All reviews are editorially independent. Where indicated, we work with some partners to provide extras to our audience, but do not accept payment for reviews.
What we like: Focus on high-performance repo parsing using async means the UI is responsive, low memory and low CPU even for the largest of repos. Keyboard control of common tasks e.g. stash, stage, diff review and commit with keybindings highlighted for newer users (or when you forget). Adopts terminal color scheme. Cross-platform packages (Arch, Fedora, Homebrew, Chocolatey, Nix).
What we don't like: No log search or file history log and does not yet support bare repos (all on the roadmap).
What we like: Real-time change indicators show where others have made changes to files but not yet committed. Preview live diffs and get warnings about conflicts from other collaborators. Privacy option to stop sharing when required. Built-in video calls and codesharing which works across IDEs - VS Code, JetBrains, Android Studio.
What we don't like: Requires everyone to use GitLive and one of the supported editors. Uploads code diffs (not the full source) to GitLive servers while changes are uncommitted, deleted once pushed.
What we like: Terminal-based signup/demo. Template / version control production commands - scripts, databases, containers, cloud consoles. CLI or Slack Bot to trigger them without direct prod access. Auth/approval flows before commands execute. Optional self-hosted runner with secrets stored in your own secrets storage. Auto-redaction of sensitive logs. Bastion SSH support.
What we don't like: Cloud version requires public access to resources e.g. database connection URL, and doesn’t support IP allowlists - self-hosted runner allows private network access. Reliant on Slack for approvals, team management, etc.
mkcert, from Filippo Valsorda
mkcert, from Filippo Valsorda
CLI for managing local dev certificates.
What we like: Solves the hassle of configuring SSL for local dev endpoints by configuring and managing a root CA. Means you don’t need to leave testing SSL to staging (or prod!) or store real certs locally. Allows you to generate certs for localhost. Cross platform + support for browser specific root stores.
What we don't like: You still need to configure your server to use the certs. GitHub binaries built with a slightly older version of Go (1.13) so no Apple Silicon support - use the homebrew version which does have Apple Silicon binaries.
What we like: Packages ranked based on various criteria such as documentation, performance, popularity. Categories for common use cases to help find most used packages. Analyze dependencies and project activity e.g. release cadence, commit frequency.
What we don't like: Only supports searching JS packages - leaderboards available for Python, Rust, Go, Swift and Java libraries. Some criteria are more subjective than others e.g. are frequent commits good or bad?
What we like: gitmoji helps identify commits at a glance. CLI sets up a Git commit hook to trigger the interactive CLI to pick a gitmoji for the commit. Text search to find right emoji based on commit purpose. Can be configured to use Conventional Commits scopes.
What we don't like: By default only renders on GitHub, but you can configure it to use actual emoji characters. Some may consider this polluting the git log, especially if you write your commits properly and use git shortlog in your release notes.
What we like: Can do arithmetic, import modules, use data types, loops, etc, because everything it receives is interpreted with Python. Tab completion based on man-pages. Community extensions e.g. Powerline, written in Python. Cross-platform.
What we don't like: Small community of extensions. Not bash compatible, so you have to relearn some syntax. Incompatible with Python virtual environments (has its own replacement called vox).
htmx, from Big Sky Software
htmx, from Big Sky Software
HTML attribute-based frontend framework.
What we like: Access AJAX, CSS Transitions, WebSockets and SSEs directly in HTML. Any HTML element can issue AJAX requests. Implements the principle of “locality of behavior” so it’s easier to understand what code is doing. Small (10k min gz), no dependencies.
What we don't like: Injecting remote responses is a potential security issue: JS can still be executed even with a restrictive CSP, and user-generated content must be escaped. Execution must be denied within specific areas of the DOM. Violates separation of concerns principle.
What we like: Open source, runs locally and/or in CI/CD. No DSL - write rules in the language you use and alongside the code they check. Plugins for as-you-code analysis in Vim, VS Code, IntelliJ. Lots of community rules for common languages and frameworks (Django, Flask, Java, Rails). Integrates with CI and can add comments to PRs. Cloud web UI is optional.
What we don't like: Experimental support for C, Rust, PHP, Lua, C#, Kotlin. No Windows support.
What we like: InfluxDB-compatible ingestion. Postgres-compatible wire API (allows querying with Grafana). Handles out of order inserts in a configurable way even though it uses an append column-based storage model. Official Docker image and Helm chart for dev/prod deploys. ANSI SQL with additional time functions. No GC.
What we don't like: No built-in replication/clustering. Partitioning is only supported by timestamp (day, month, year) which means you tradeoff easier retention policies and faster calculations/seek times with the potential for hotspots if reads are mostly on recent data.
What we like: Search shell history with CLI or interactive TUI (ctrl+r). Query by date, current directory, string terms. Encrypted sync across machines with log of exit code, session, command. Fun stats e.g. “most used command”. Option to run your own sync server.
What we don't like: Can’t delete entries from history. Default rebind on up-key takes some getting used to, or disable it in config. Only supports zsh and bash.
What we like: Google Docs-style real-time sharing / editing. Detects dependencies, prompts for pip install and updates requirements.txt. Running the Jupyter environment in the cloud saves hassle installing kernels locally. Integrates with git. Public links. Supports Python & R.
What we don't like: Visualizations are custom HTML embeds when exported to Jupyter notebook format - better to embed something like Plotly in code to ensure portability.
What we like: No dependencies. No build step. Very small (~400 LoC vDOM, ~100 LoC state management, ~230 LoC HTML helpers). Works with async components. Web tutorial does a good job explaining how it works (built using itself).
What we don't like: No router. Great for very simple SPAs, but something like Mithril.js (or Vue. Or Svelte) probably needed for anything of significance (if you don’t mind the build step).
What we like: Saves building your own queuing system - acts as a proxy to store and forward webhooks. Set up throttling and retry rules. Mirror inbound webhooks to multiple destinations, including a local CLI for testing. Alerts on failures - allows you to search & retry failures so you don’t lose any data.
What we don't like: Assumes your webhook destinations are idempotent with “at least once” delivery. No support for signature verification - will forward all requests (you can configure schema filters), so you need to implement this yourself. No support for custom webhook URL domains.
What we like: Local simulation of the GitHub Actions environment using Docker. Much faster than commit/push for testing changes. Supports environment variables and secrets. Can trigger specific events e.g. pull request, push, and jobs within workflows (including skipping steps).
What we don't like: Only supports Linux runners (host is multi-platform). Full Docker images are quite large (>20GB), but you can try slimmer images with fewer bundled tools.
What we like: Packages for all platforms (+ Nix, AUR, musl). Uses relaxed SQL to support fields e.g. size, path; operators e.g. AND, gte, like; date queries e.g. created, modified; filename glob and regex. Can use .gitignore and search MP3, MIME and other file attributes. Output in CSV, JSON, HTML.
What we don't like: Requires the absolute path (~/path doesn’t work), or searches current working directory if no path provided. Be careful to use quotes if you use shell characters such as >
git-xargs, from Gruntwork
git-xargs, from Gruntwork
Execute commands across multiple git repos.
What we like: Write a script to make a change to a single Git repo, then apply that change across multiple (specified in a list, or entire GitHub Org). Executes in parallel. Can open GitHub PRs with changes. Lots of use cases for otherwise tedious work e.g. name changes, updating dependencies, mass config changes.
What we don't like: Only supports GitHub PRs, but can push remote branches. Releases only available as binaries, no packages (you can use go get). Sometimes scripting these things actually takes longer than doing it manually.
What we like: Drop-in replacement for Redis. Claims x5 speed boost from multi-threading. Adds some extra features like backup to S3 and active replication. Potentially reduces operational complexity by shifting scaling to CPU cores and network throughput rather than requiring clustering.
What we don't like: Runs the normal Redis event loop on multiple threads which requires locking (low contention, but work ongoing to improve). Expects exclusive use of assigned CPU cores.
Thunder Client, from Ranga Vadhineni
Thunder Client, from Ranga Vadhineni
An HTTP client for VS Code.
What we like: Easily build HTTP requests with custom params, auth (basic, bearer, OAuth), headers and body (text, JSON, XML, form, GraphQL). Parses and syntax highlights response, headers and cookies. Can create automated tests with conditions such as response time, status codes, headers, etc.
What we don't like: All local - no config sync or dynamic loading from config files, but configs can be exported and imported.
REST API Generator, from Retool
REST API Generator, from Retool
Build an API to develop against.
What we like: Create a read/write REST API to start building against before your backend is ready. Supports all HTTP verbs. Lots of default field types with sample data e.g. location, emails, avatars, credit cards.
What we don't like: Limited to 150 rows. Hosted by a third party, so don’t send anything sensitive. Deleted after 30 days of inactivity.
llama, from Nelson Elhage
llama, from Nelson Elhage
CLI for parallelizing commands inside AWS Lambda.
What we like: Makes it easy to burst parallelizable commands into Lambda. Uses Go template language for managing input and output. Supports Docker wrappers to bootstrap environments. Includes a drop-in GCC/clang replacement for outsourcing compilation.
What we don't like: Lambda is CPU and memory constrained, and the network is a bottleneck, so use cases are constrained to where parallelization makes a big difference (or there is a benefit to freeing local resources).
What we like: Single binary (C++) runs natively on Linux and macOS. Tunable ranking for relevancy score tie-breaks. Sort at query-time without additional indexes. Scoped API keys. InstantSearch.js adapter. REST API with clients for JS, PHP, Python, Ruby. Open source + cloud option.
What we don't like: Need to build your own index updater mechanism to process new data. API-only means you need to build your own UI/admin. Only supports Latin-based languages.
What we like: Offering webhooks is actually more complex than you'd expect. Diahook deals with signing requests, queueing, retries, reliability, auth, E2E encryption, rate limiting, logs and debugging.
What we don't like: You need to send your events to Diahook, which means you still need to ensure they get there (retries, debugging, etc).
What we like: Deals with the underlying infrastructure for reliable task execution: state management, retries, scaling, fault tolerance. Avoid building and running your own timers / queues - just write the function business logic. Open source server you can run yourself, or use their cloud option (in private beta).
What we don't like: SDKs are still being built out (currently available for Go, Java, PHP, Ruby). You still need to run / scale your own database (Cassandra, MySQL, or PostgreSQL).
What we like: Intercepts all XMLHttpRequest and fetch requests so no code changes required (one additional import). Includes in-memory database for persistence tests. Can simulate slow responses or errors. Built-in ORM handles data relationships, output formatting, serialization.
What we don't like: Only supports REST APIs out of the box - GraphQL available as an optional plugin (still in development). Runs in the browser, not as a server, so it cannot be used to mock server-side APIs.
What we like: Forces you to think about what you are going to work on in advance - writing out a plan probably helps improve your thinking, and also creates better commit messages. If you think of something you need to switch to, you can create a plan whilst it’s still top-of-mind, then come back to it later.
What we don't like: Unintuitive to begin with, but makes sense once you try it (see blog posts linked in the project readme for guidance). Interactive rebasing is an alternative that doesn’t force you to reverse your workflow.
What we like: Quickly create step function APIs from lots of pre-built integrations. Cron support. Connect to external data sources and manipulate data. Write real Python, JS, Java, shell script, GraphQL, HTML, and SQL (including using packaged dependencies) as separate steps. Configurable editor e.g. use vim keybindings, tabs vs spaces, etc.
What we don't like: Can be slow to execute (many seconds) especially with lots of steps. Have to use their browser editor - can’t develop and run code locally (this is on the roadmap).
What we like: Fast execution of steps due to caching. Can retry builds from specific steps and live-debug in a terminal which makes setting up pipelines easier. Can switch between UI or YAML config. Commenting/sharing helps team collaboration. UI has useful features, such as env var autocompletion.
What we don't like: Ecosystem of official build actions is small relative to GitHub Actions. UI is sometimes confusing due to the number of config options.
What we like: Open source & self hosted: you probably don't want to build all your own user management (signup, login, MFA, FIDO2, etc) but do care about control and ownership. Runs as a compact, single Go binary. JSON Schema data model. Headless; example UI and API SDKs for Python, PHP, Node, Go, Java, Ruby. Scale horizontally.
What we don't like: Focus on APIs means there is no admin UI. Federation (OAuth2, OpenID) requires a separate project (ORY Hydra). "Scale horizontally" still means you need to scale your own RDBMS. Pre-1.0, targeting "stable" in 2022.
What we like: Autocomplete and flag suggestions. Commands such as release or sync combine several commands in one to speed up common tasks. Branch autocomplete for checkout. GitHub PR integration. Support for themes. Open source & cross platform.
What we don't like: Not what you might expect from a cli: you run the bit command, then it suggests subcommands and flags, rather than tab completion. Official OS packages missing on Linux.
What we like: Captures screenshare and click journey with associated metadata like console and network logs. Local-first; uploadable for sharing (private or public). Quick submit to JIRA, Linear, Trello, GitHub
What we don't like: Chrome only (works on Microsoft Edge). More integrations needed.
What we like: Runs existing build steps inside a container using your existing CI system (Jenkins, CircleCI, GitHub Actions, etc). This makes builds reproducible locally so they run the same on your laptop as in remote CI. Steps can be parallelized. Dependency caching locally and across repos.
What we don't like: Assumes you are building an already containerized application. Multi-platform builds are experimental.
Playwright, from Microsoft
Playwright, from Microsoft
Automate Chromium, Firefox & Webkit with a single API.
What we like: Single API to launch and script Chromium, Firefox and WebKit. Emulate devices for testing responsiveness. Auto-wait API avoids hard coding timeouts. Extract screenshots, video and debug info. Library for JS, TypeScript, Python, C#, Java. Works on Windows, macOS, Linux.
What we don't like: Only supports latest browser versions - can’t pick older versions to test against. Browser binaries are quite large so may slow down CI/CD (cache is configurable).
What we like: Build OpenAPI (v2 Swagger or v3) compliant APIs with auto-generated docs, example code, and mocking. Write docs in Markdown. Save everything (and load existing APIs) from Git. Offline/local dev support with desktop API studio app.
What we don't like: Limited ability to customize doc output to fit into your own design/brand. Some editor/docs UI bugs in Firefox. It does work without using OpenAPI specs, but most features assume you do.
What we like: Search cloud and local documents. Clipboard history. Manage GitHub PRs, JIRA issues, join Zoom calls, schedule calendar blocks. API and scripting to create your own commands. Tiling window management. Connects directly to remote services to avoid privacy issues.
What we don't like: macOS only. Shortcuts for sub-commands are difficult to find. File search requires scoping rather than searching everywhere.
What we like: Autocomplete and syntax highlighted output. Support for Postgres, MySQL, SQLite, MSSQL, Redis, AWS Athena. History, search, vi/Emacs keybindings, saved queries. Open source & cross-platform.
What we don't like: Only available via pip or brew - official OS packages would make installation easier to integrate with native package management. Installation on Windows is a hassle due to needing Python. Large results don't line-wrap well.
404 Tools Not Found. Try changing the filters.
Interesting Tools by email
Our free weekly newsletter picks out the 2-3 most interesting tools. See the latest email.