Console
Developer tools reviews
Console reviews and features the best tools for developers.
Interesting Tools by email
Our free weekly newsletter picks out the 2-3 most interesting tools. See the latest email.
Interesting Tools by email
Our free weekly newsletter picks out the 2-3 most interesting tools. See the latest email.
Latest Tools
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.
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.
Terrascan, from Accurics
Terrascan, from Accurics
Static code analyzer for Infrastructure as Code.
What we like: Scans Terraform, k8s, and Helm configs for security and compliance. Supports AWS, Azure, GCP, Kubernetes, GitHub and has lots of sensible policy defaults which can be extended using the Open Policy Agent Rego language. Can be run in CI/CD.
What we don't like: Docs need work: quickstart didn't work smoothly and default policies are not well explained. Explanations of how to rectify policy violations would help.
What we like: Flexible, declarative language for describing simple or complex access control rules in code. Easy to test policies. Native libraries for NodeJS, Java, Python, Ruby, Go, Rust. Useful tooling: debugger, tracer, and VS Code integration.
What we don't like: Focused only on authorization, so you need to build your own authentication (signup, login, forgot password, etc).
What we like: .gitpod.yml file in the repo describes the full dev environment so it's version controlled and always up to date. GitPod pre-builds after every commit so the environment is ready when you activate it. VS Code in the browser means you can develop anywhere on any machine. Easily switch workspaces e.g. to review a pull request without disrupting your current environment. Self-hosted version so you can run it all yourself (some features limited to paid license).
What we don't like: Limited IDE support - VS Code or Theia (based on VS Code) means you have to code in the browser so you can't use your own IDE/editor (support for other IDEs in development). Requires you to be online with good connectivity because everything is remote.
What we like: Makes it easy to switch language runtime versions without messing up the system install (if any). Lots of plugins so it supports pretty much every language. Configs can be defined in a per-project file so it can auto switch based on current working directory. Means you can forget about language specific virtual environments because asdf manages them for you. Has an official GitHub Action.
What we don't like: Language support is via community plugins so quality is variable. Windows support still in development.
What we like: An easy way for developers to run a standardized suite of black box tests. Spiders and auto-discovers endpoints so there is almost zero config. Runs inside a container so it can be run anywhere. Web UI highlights and prioritizes all detected vulnerabilities. Can easily be run locally against any local or remote endpoint. Built on top of open source OWASP ZAP. Good quality documentation. Integrations into CI/CD e.g. GitHub Actions, GitLab, CircleCI.
What we don't like: Assumes you know about OWASP and how to resolve highlighted issues. The nature of black box testing means some OWASP issues are false positives and are not comprehensive e.g. no detection of dependency vulnerabilities. Large example app takes >25min to scan (although our own simple app took <1 min).
Opstrace
Opstrace
A management layer on top of independent open source observability tools.
What we like: Automates deployment of Prometheus, Cortex, and Loki and configures them to store data in your own S3 or GCS buckets. This means you keep control of the data and the price of storage from your existing cloud provider. Supports multiple tenants e.g. prod vs dev, and deals with scaling them. Existing Prometheus instances can be configured to send data to Opstrace.
What we don't like: Installation and cluster management are the main differentiator - otherwise it's just packaging open source projects. API uses an Opstrace managed endpoint - custom domains supported only in the commercial version which is hidden behind "contact us". If you already have Prometheus, you could just set up Cortex yourself. Only supports AWS and GCP. No Windows support.
What we like: The first thing you notice is running `ls` outputs a structured table. All output is actually data, so it is like interacting with a spreadsheet. Nushell applies the Unix philosophy of piping commands but allows for commands like `ls | where size > 1kb`. Supports parsing data like CSV and JSON. You can script your own commands. Cross platform.
What we don't like: Although it can be run as a command, it is designed to replace your existing shell. It is still in development so may not be stable. You will have to reconfigure everything if you have heavily customized your shell.
Etebase, from EteSync
Etebase, from EteSync
E2E encrypted Firebase-like database and SDK.
What we like: Open source end-to-end encryption based on libsodium. SDKs for JS, Python, Java, Kotlin, C/C++, Rust. Handles sync and user sharing e.g. users collaborating on an encrypted doc. Has specialist types for calendars, tasks, and Markdown notes. Supported by a foundation and a European Commission program.
What we don't like: A cloud service by default but you can run their open source server component. No pricing yet for the commercial cloud version. Large files not supported (on the roadmap). Local cache but no offline storage.
What we like: Integrates with CI (GitHub, GitLab, CircleCI, Bitbucket) to provide cost diffs for pull requests. Supports AWS and Google Cloud.
What we don't like: Uses a Cloud Pricing API provided (for free) by the Infracost project so it requires sending data to it (you can self-host). May be out of date. Only supports AWS and Google Cloud. Other cloud vendors planned.
What we like: Deploy a full AWS stack in a local Docker container. Avoid paying for AWS environments for test/dev. Supports key AWS services like DynamoDB, EC2, Kinesis, Lambda, Route53, SNS, SQS. Allows you to inject errors.
What we don't like: Some APIs require the paid version e.g. CloudFront, Cognito, ElastiCache, Glacier, RDS. Not built by AWS so will always lag behind the real thing. Good for dev but testing probably better done against the actual APIs.
What we like: rsync.net is a Unix (ZFS) filesystem over SSH but also supports commands like borg, git, rsync, s3cmd, and now rclone. rclone is a separate open source project that exposes many cloud accounts as filesystems e.g. Google Photos, Dropbox, Azure Blob storage. rsync.net connects directly so you can copy from one to the other without downloading/uploading.
What we don't like: This is truly a filesystem over SSH so you need to know your way around the command line. Documentation is limited and the account manager UI is dated. No support for scheduling execution so you need to handle that yourself e.g. cron, systemd.
extrakto for tmux, from laktak
extrakto for tmux, from laktak
Quickly select, copy/paste, complete text without a mouse.
What we like: The whole idea behind using the command line is to make things faster, usually using the keyboard. This helps with that goal by improving select, copy and paste inside tmux. It works everywhere, even in SSH sessions. Works with clipboards on Linux, macOS, and Windows.
What we don't like: tmux beta release is required for popups, otherwise this currently uses a new split window.
What we like: Managing lots of individual Lambdas across environments and regions is a pain because of how long it takes to package and deploy, especially with AWS rate limits. Seed hooks into Git and speeds things up by deploying concurrently. Supports Serverless Framework, caching dependencies, and incremental deploys. Built-in Lambda monitoring for errors. Also supports AWS CDK.
What we don't like: Only supports AWS Serverless i.e. Lambda, so unless you are 100% Lambda then this will be a separate CD pipeline to manage. Doesn't support other tech like containers, or other platforms like Azure/Google. Those with just a few, simple Lambdas may find it overkill.
IPFS Support in Brave
IPFS Support in Brave
Support for accessing content over the decentralized network, IPFS.
What we like: Decentralized filesystems allow access to content without relying on a specific host. This makes them resistent to censorship (or outages, deletion, etc). IPFS can be a pain to run, or you have to use a gateway service. Built-in browser support means users don't have to care, just like with HTTP. Brave is based on Chromium (but better privacy than Chrome) so most sites work fine.
What we don't like: Brave is still a niche browser, and IPFS is still very early. How much content is hosted on it? Site owners need to upload (pin) their content to IPFS, which isn't necessarily straightforward. Still requires the use of ipfs:// URLs, although DNSLink support for using DNS TXT records is planned.
What we like: macOS Big Sur includes a new framework for managing VMs. This CLI makes it easy to run VMs without additional software i.e. using the new Virtualization.framework. Means you don't need Virtual Box, VMWare, etc for simple VM tasks.
What we don't like: Obviously macOS-only. Only basic functionality for using VMs (probably fine for developers).
What we like: AWS Console UX is not great; Vantage is much cleaner and faster. It connects using a read-only CloudFormation IAM Role and they have detailed documentation about the read-only permissions it requests. "Views" nicely segment/group resources, even across accounts and regions, with global search for them all. Cost reporting by view and weekly email reports help you manage budgets better.
What we don't like: Does not support all AWS products, currently focused on a few key resources e.g. EC2 instances, VPC Subnets, Route53, etc. Currently read-only, which is good for security and because it's a new tool - plans to add more management features in the future. Also AWS-only, but they are working on other cloud providers.
What we like: Web UI and SDKs for uploading files to a decentralized CDN. Uses a blockchain and rewards users who run nodes with coins which can be exchanged for money. Current average cost = $4.16/TB stored + $1.25/TB transferred.
What we don't like: Time to first byte 300-500ms may be prohibitatively slow for some use cases. Streaming "up to 1Gbps" but what does "up to" really mean? Files must be public. Why call it "Skynet"?!
Stork Search, from James Little
Stork Search, from James Little
Fast search for static sites.
What we like: Generate the index of your content, which is then downloaded by the visitor's browser and searched using the JS/WASM library "locally" - this is what makes it so fast.
What we don't like: Index must be generated manually. It is specifically designed for static sites, so it would need to be hooked into a build process. Would need extra work if you wanted to index a dynamic site.
What we like: Works with any shell (bash, zsh, fish, PowerShell). Context-sensitive e.g. auto-complete, shows Git info, lots of language specific configs. Written in Rust, which is trendy, and probably fast.
What we don't like: Another layer on your shell to mess around with. If you use ZSH then Oh My ZSH already does a lot of this, and has lots of good ZSH tweaks.
Wasmer 1.0
Wasmer 1.0
An open-source runtime for executing WebAssembly server-side.
What we like: Allows shared libraries to be sandboxed, compiled, then run standalone or embedded in Rust, C/C++, Python, Go. Pluggable compilers allows optimisation of the final artifacts e.g. LLVM for machine code. Wasmer 1.0 adds a headless mode and cross-compilation.
What we don't like: The use cases seem limited to untrusted, shared code. If you need cross-platform, native binaries with good performance then why not just use a compiled language like Go or Rust in the first place?
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.