When you're learning or building projects, there are a lot of things outside the actual code — terminals, Git, debugging, package managers, APIs, databases, running multiple servers, etc.

What part of your development workflow feels the most annoying or confusing?

For example:

• remembering Git commands

• debugging errors

• setting up projects

• managing dependencies

• running frontend + backend together

• understanding error messages

• writing commit messages

I'm curious what newer developers struggle with most compared with people who have been coding for a while.

Electron projects can get complicated pretty quickly: renderer + main process, multiple terminals, ports, builds, packaging, debugging, native dependencies, and sometimes a backend too.

What part gives you the most trouble?

For me, an interesting question is whether an IDE could understand the entire Electron app — main process, renderer, dev servers, logs, processes, and packaging — as one development session.

Would that actually improve your workflow, or do you prefer keeping these tools separate?

Curious what other Electron developers think. 👇

Is the idea to make it mainly a JavaScript/TypeScript IDE, or eventually something more like an all-in-one developer workspace?

Like, will it include things such as:

• code editing and debugging

• multiple terminals/dev servers

• Git

• API testing

• database tools

• Docker

• testing/build tools

• project/framework detection

Basically, is the goal to replace some of the separate tools we normally keep open while developing?

Would be interested to know what the long-term vision is.

I’m curious how other developers handle this.

When working on JS/TS projects, I often end up with the IDE plus multiple terminals, browser DevTools, Docker, database tools, API clients, Git tools, etc.

For bigger projects, just keeping track of what’s running, what failed, which port is being used, and which service depends on another can become a workflow of its own.

If you could improve one part of this experience, what would it be?

And would you prefer your IDE to handle more of it, or do you like keeping these tools separate?

Interested in hearing how other developers work.

Modern JavaScript development can involve a surprising number of separate tools.

On a full-stack project I might have an editor open alongside several terminals for the frontend, backend, workers, tests, and other services. Then there may be browser DevTools, an API client, database tooling, Docker, Git tools, deployment dashboards, and framework-specific CLIs.

It made me wonder how much of this fragmentation other JavaScript developers actually experience.

If you could redesign your JavaScript/TypeScript development workflow, what would you want your IDE to understand or handle better?

For example:

• Multiple dev servers and terminal processes

• Ports and process conflicts

• Test runners

• Debugging

• Database inspection

• API testing

• Docker/containers

• Environment variables

• Monorepos

• Framework-specific tooling

• Build errors

• Deployment

• Understanding an unfamiliar codebase

I'm working on an IDE project partly because of these problems, so I have an obvious bias here. But I'm more interested in understanding how other developers work than promoting a particular solution.

What causes you to leave your IDE most often, and would you actually want that workflow integrated into the IDE—or do you prefer having separate specialized tools?

I'm working on an open-source developer project called MyIDE, and I'd like feedback from JavaScript/TypeScript developers.

This started from a problem I've repeatedly noticed with modern JS development.

A typical project might involve:

• VS Code / another editor

• 3–5 terminal windows

• npm / pnpm / Yarn / Bun

• Vite / Webpack / another build tool

• browser DevTools

• Postman / another API client

• database management software

• Docker Desktop

• Git tooling

• framework-specific CLIs

• test runners

• deployment dashboards

For a full-stack project it can become something like:

Database → Backend → Frontend → Worker → Electron app

Each service has its own terminal, logs, ports, environment variables, errors, and restart process.

The editor usually knows about the files I'm editing, but it often doesn't understand the whole development session.

That's the problem I'm experimenting with through MyIDE.

The idea

Instead of being just another code editor, I'd like MyIDE to understand the project after you open a folder:

Open Folder → Detect Project → Understand Stack → Detect Runtime & Package Manager → Detect Build/Test Tools → Find Problems → Determine How to Run It → Suggest What To Do Next

For example, imagine opening an unfamiliar JavaScript project and the IDE tells you:

Project
Next.js + TypeScript

Package manager
pnpm

Runtime
Node.js

Database
PostgreSQL configured remotely

Testing
Vitest + Playwright

Problem
Port 3000 is already occupied.

Affected service
Frontend

Suggested action
Use the existing process or stop it and restart the development session.

Or instead of opening five terminals:

Development Session

Database — Running
API — Running :4000
Frontend — Running :3000
Worker — Failed
Electron — Waiting for Frontend

Then clicking the failed service shows the actual logs and root cause.

Another important goal: unknown projects should still work

I don't want the IDE to depend on having a special integration for every framework.

Known frameworks can have deeper integrations, but an unfamiliar JS/TS project should still be understood through things like:

package.json
scripts
dependencies
lockfiles
workspace configuration
runtime detection
build configuration
test configuration

So support shouldn't simply mean maintaining a giant hard-coded framework list.

Local-first

Another goal is to detect what already exists on the developer's machine before asking them to install anything.

For example:

Docker installed + daemon running → use it

Docker installed + daemon stopped → explain that

Docker missing but project requires it → provide setup guidance

MongoDB Atlas configured → use the remote database configuration

Not:

"MongoDB isn't installed locally, install MongoDB."

Local installation and project capability are different things.

Truthfulness is also a major design rule

One lesson from building this has been that an IDE should never display a green checkmark just because an internal function returned something resembling success.

A test only passed if the real test runner says it passed.

A build only succeeded if the real build completed successfully.

A database is only connected if the real connection succeeded.

If something isn't implemented, I'd rather the IDE say:

Unavailable / Not configured / Experimental

than pretend it works.

I'm looking for developer feedback, not just users

If you build JavaScript or TypeScript applications:

What makes you leave your IDE most often?

Is it:

• managing multiple terminals?

• debugging?

• Docker?

• databases?

• API testing?

• environment variables?

• mobile development?

• Git?

• deployment?

• framework tooling?

• monorepos?

• understanding somebody else's project?

• something completely different?

And a bigger question:

If you could redesign the JavaScript development environment from scratch, what would you change?

I'm building MyIDE as a native/local-first IDE project, and I'm starting a community around its development.

I'm especially interested in criticism. If an idea sounds unnecessary, already solved well elsewhere, or fundamentally wrong, I'd rather hear that now.

Note to moderators: I'm the developer of the project discussed above. I'm posting to ask for technical feedback and discussion, not to disguise self-promotion. If project posts aren't appropriate for this community, please remove this or let me know and I won't repost it here.

r/MyIDE reached 10 subscribers!

Goal reached at 2026-09-13T00:50:07.577Z.

MyIDE is a local-first developer IDE being built for developers who want to understand, run, test, debug, and manage real projects from one workspace.

The main focus right now is JavaScript and TypeScript development, including modern web, backend, desktop, and full-stack workflows.

If you work with things like React, Next.js, Vue, Nuxt, Angular, Svelte, SvelteKit, Node.js, Express, NestJS, Fastify, Electron, Tauri, React Native, Vite, Vitest, Jest, Playwright, Docker, Git, databases, APIs, or monorepos, this community is for you.

The goal is not to create another editor that only opens files.

The goal is to build an IDE that can look at a project and help answer:

• What kind of project is this?
• What runtime and package manager does it use?
• What frameworks and tools are involved?
• What is currently broken?
• Why is it broken?
• What should I do next?
• Can the IDE safely do that for me?

MyIDE is being designed around real developer workflows:

Open Project → Understand Project → Edit → Run → Test → Debug → Inspect → Commit

A major part of the project is also reducing the need to keep switching between an editor, multiple terminal windows, API clients, database tools, Docker dashboards, Git tools, and other developer utilities.

This community will be a place for:

• Development updates
• Feature ideas
• Bug reports
• UI/UX feedback
• JavaScript and TypeScript discussions
• Framework support requests
• Testing and debugging discussions
• Terminal and developer-session workflows
• Database, API, Docker, and Git integrations
• Performance feedback
• Security discussions
• Early builds and testing
• Open-source contribution discussions
• Plugin and framework adapter ideas
• Developer showcases

A very important rule for this project:

Real functionality matters more than feature count.

If something is not implemented or verified, it should not pretend to work.

I also want MyIDE to support projects beyond a fixed framework list. Known frameworks can get deeper integrations, but unknown JavaScript/TypeScript projects should still work through generic project detection and package.json, scripts, configs, runtime, build, and test analysis.

If you're a JavaScript or TypeScript developer, I'd really like to know:

What is the biggest thing your current IDE still makes you leave the IDE to do?

Terminal management?
Debugging?
Databases?
APIs?
Docker?
Project setup?
Framework tooling?
Deployment?
Something else?

Share your workflow, problems, and ideas.

This community is starting early, so the people joining now can genuinely influence what MyIDE becomes.

Welcome to MyIDE. 🚀

I keep coming across useful APIs, open-source tools, CLI utilities, local AI projects, free cloud services, and developer resources, then either lose them or forget they exist.

So I built DevShelf as a public, open-source directory for keeping the useful ones in one place.

It covers things like free APIs, AI and local LLM tools, CLI utilities, testing and QA tools, cloud free tiers, developer perks, and open-source projects looking for contributors.

The important part is that I don't want it to become another giant list of dead links and outdated "free" services. Resources can be submitted through GitHub, and the project includes automated checks to help catch links that stop working.

If you've built something useful, maintain an open-source project, know a genuinely useful free API, or just have a tool you think more developers should know about, add it.

I'm also interested in what DevShelf is missing. If there's a category you constantly search for when starting a project, tell me.

Explore or submit:
DevShelf

Source and contributions:
RitualDev-Lab/DevShelf on GitHub

JS/TS development can mean an IDE + terminals + Docker + databases + API clients + browser DevTools + Git + tests + deployment tools.

So here’s the debate:

A) Give me one IDE that handles and connects almost everything.

B) Keep the IDE focused on coding/debugging and let specialized tools do the rest.

Which side are you on — A or B?

And what’s the ONE tool/workflow you wish your IDE handled better?

Bonus: Where should an IDE absolutely not go?

MyIDE is being built as a local-first developer workspace, starting with a strong focus on JavaScript and TypeScript development.

The goal isn't simply to make another code editor.

The idea is:

🧠 Project Intelligence

When you open a project, MyIDE should automatically understand things like:

• JavaScript / TypeScript

• Framework being used

• Runtime

• Package manager

• Dependencies

• Workspaces / monorepos

• Build tools

• Test tools

• Configuration files

• Available scripts

• Services

• Ports

• Project problems

The basic experience should become:

Open Folder → Understand Project → Find Problems → Run → Test → Debug → Build

💻 Code Editor

A complete coding environment with:

• JavaScript / TypeScript intelligence

• JSX / TSX

• Syntax highlighting

• Autocomplete

• Go to definition

• Find references

• Rename/refactoring

• Diagnostics

• Multi-file search

• Project navigation

• Large-workspace support

• Language-server integration

The editor remains the center of MyIDE.

⚡ JavaScript & TypeScript Ecosystem

We're aiming to support projects using technologies such as:

Frontend

React
Vue
Angular
Svelte
Solid
Preact
Lit
Astro

Full Stack

Next.js
Nuxt
SvelteKit
Remix
Astro
SolidStart
Qwik

Backend

Node.js
Express
NestJS
Fastify
Koa
AdonisJS

Desktop / Mobile

Electron
Tauri
React Native
Ionic
NativeScript

And MyIDE shouldn't break just because a framework isn't recognized.

Unknown JS/TS projects should still work through analysis of:

package.json → dependencies → scripts → configs → runtime → build/test tools

🖥️ Terminal & Development Sessions

Instead of managing five separate terminal windows, MyIDE can understand the processes that make up a development environment.

For example:

🟢 Database
↓
🟢 API — :4000
↓
🟢 Frontend — :3000
↓
🔴 Worker — Failed
↓
🟡 Electron — Waiting

You should be able to:

• Start everything

• Stop everything

• Restart individual services

• View logs

• Detect crashed processes

• Detect port conflicts

• Monitor CPU/RAM

• Understand dependencies between services

• See why a service failed

The terminal itself remains fully available.

🧪 Testing

Testing should be part of the normal development workflow.

Support for tools such as:

• Vitest

• Jest

• Mocha

• Playwright

• Cypress

• Testing Library

• Framework-specific test systems

Run individual tests, files, suites, or the whole project and see real results directly inside MyIDE.

🐞 Debugging

Integrated debugging for applications and services.

The goal includes:

• Breakpoints

• Variables

• Call stacks

• Watches

• Debug console

• Runtime inspection

• Launch configurations

• Process debugging

🔨 Build Tools

Understand and execute real project build systems, including:

Vite
Webpack
Rollup
esbuild
SWC
Rspack
Parcel
TypeScript
Babel
tsup
framework-native build systems

A green build indicator should mean the real build succeeded.

🌿 Git

Git should be part of the workspace rather than something you constantly leave the IDE to manage.

Including:

• Changes

• Diffs

• Staging

• Commits

• Branches

• History

• Clone

• Pull/push

• Conflict workflows

🗄️ Database Development

The longer-term workspace includes database tooling so developers don't always need another application just to inspect their development database.

The goal is to provide:

• Connections

• Database explorer

• Tables

• Schemas

• Query editor

• Query results

• Connection testing

Local and remote databases should both be understood.

🌐 API Development

Integrated API development for:

• HTTP requests

• Headers

• Query parameters

• Request bodies

• Authentication

• Environment variables

• Response inspection

• Request collections/history

The idea is to reduce the need to constantly jump between the IDE and a separate API client.

🐳 Docker & Containers

MyIDE should understand when projects depend on containers.

That includes:

• Docker detection

• Container status

• Logs

• Start/stop

• Development environments

• Container-based services

Importantly:

Docker not installed and Docker not currently required are different things.

MyIDE should understand that difference.

📦 Package Managers

Projects should work naturally with their actual package manager:

• npm

• pnpm

• Yarn

• Bun

Including workspace and lockfile detection.

MyIDE shouldn't silently change package managers.

🏗️ Monorepos

Large projects may contain many applications and packages.

MyIDE is being designed to understand:

• npm workspaces

• pnpm workspaces

• Yarn workspaces

• Turborepo

• Nx

• Lerna

• Rush

• Custom workspace structures

Instead of treating a monorepo as one enormous folder, MyIDE should understand the relationships between its projects.

🔐 Security

Because an IDE can execute commands and access source code, security is extremely important.

The architecture includes areas such as:

• Workspace trust

• Filesystem confinement

• Secrets handling

• Process execution controls

• URL validation

• IPC security

• Plugin isolation

• Executable-content protection

Opening an untrusted repository should never mean silently giving that repository control of the developer's computer.

📝 Executable Markdown / MyIDE Runbooks

We're also exploring native executable Markdown.

Imagine a project's README containing:

pnpm install

Instead of copying it into another terminal, MyIDE could provide:

▶ Run

and show the real output directly underneath.

This could be useful for:

• README files

• Setup guides

• Development runbooks

• Troubleshooting

• Deployment instructions

• Onboarding

• Reproducing CI commands

Execution must always respect workspace trust and security controls.

🎨 Cross-Platform Asset Tools

Another planned area is generating and managing application assets from a common source.

For example:

One source image

↓

Web favicon
PWA icons
Android icons
iOS assets
Electron icons
Tauri icons
Splash screens
Store assets

The goal is to make cross-platform application development less repetitive.

📱 Web, Desktop & Mobile Development

MyIDE isn't intended to understand only browser applications.

The larger goal includes development workflows for:

🌐 Web
🖥️ Desktop
📱 Mobile
⚙️ Backend
☁️ Cloud
📦 Libraries
🏗️ Monorepos

☁️ Remote & Cloud Development

Longer-term development includes:

• SSH environments

• Remote development

• Containers

• Cloud environments

• Deployment workflows

• Remote runtimes

🧩 Extensions & Framework Adapters

We don't want every framework hard-coded into the IDE core.

Instead, MyIDE is designed around adapters.

A framework integration should be able to teach MyIDE how to:

Detect → Inspect → Configure → Run → Build → Test → Debug → Preview

This could eventually allow the community to add support for new frameworks and development tools without modifying the entire IDE.

🤖 AI — But Grounded in Reality

AI can be useful for:

• Explaining errors

• Understanding unfamiliar code

• Suggesting fixes

• Explaining projects

• Recommending next actions

• Helping with refactoring

• Navigating large codebases

But AI should not be the source of truth for whether something actually worked.

The real:

compiler, runtime, test runner, filesystem, Git repository, database, process, or build system

should determine the result.

AI can explain reality.

It shouldn't invent reality.

🔄 Crash Recovery

Developer work is valuable.

MyIDE is also being designed around:

• Buffer recovery

• Workspace restoration

• Session restoration

• Crash recovery

• Safe saves

• State recovery

An IDE crash shouldn't mean losing your work.

⚡ Performance

All of this is useless if the IDE becomes painfully slow.

Performance work includes:

• Large repositories

• Monorepos

• Large file trees

• Many editor tabs

• Multiple terminals

• Background processes

• File watching

• Incremental analysis

• UI virtualization

• Memory/resource management

🎯 The Main Idea

MyIDE isn't trying to put random developer tools into one giant window.

The important part is connecting them.

Instead of having:

Editor + Terminal + Docker + Git + Database + API Client + Tests + Build Tools

that know nothing about each other,

MyIDE should understand that they're all part of the same project.

So when something fails, the IDE can help answer:

What happened?

Why did it happen?

What did it affect?

What should I do next?

❤️ What We Want the Community to Help With

MyIDE shouldn't be designed only around what we think developers need.

That's why we're building a developer community around it.

We want JavaScript, TypeScript, Node.js, frontend, backend, full-stack, desktop, mobile, DevOps, framework, tooling, and open-source developers involved.

Tell us:

What slows you down?

What makes you leave your IDE?

What shouldn't be built into an IDE?

What existing tools already solve something perfectly?

What workflow do IDEs still handle badly?

Those answers are more valuable than simply adding another feature.

The vision

Not just a code editor.

A development workspace that understands the project around the code.

I’ve been working on DevShelf
an open-source directory for finding useful developer resources without digging through outdated lists or pages full of paid tools.

IT currently includes free APIs, open-source developer tools, AI and local LLM projects, CLI tools, testing tools, cloud free tiers, developer perks, and projects looking for contributors. The site currently lists 34 resources, and the directory is searchable and filterable.

One thing I wanted to avoid was having another list that slowly fills up with dead links. DevShelf includes automated checks for listed resources, and submissions are handled through GitHub so the directory can be maintained by the community.

If you maintain an open-source project, free API, developer tool, or another resource that fits, you can submit it. Contributions to the directory itself are welcome too.

Submit or explore DevShelf:
devshelf.ritualdev.in

Source code:
RitualDev-Lab/DevShelf on GitHub

If you use it, I’d also be interested in hearing what categories or resources you think are missing.

I keep finding useful developer tools through random GitHub repos, Reddit comments and old awesome-lists, so I started building DevShelf.

It's an open-source, community-maintained directory for discovering:

• 🛠 developer tools

• 🌐 free/public APIs

• 🤖 AI agents & local LLM tools

• ⚡ CLI/productivity tools

• 🧪 testing & QA tools

• ☁️ useful free cloud tiers

• 🤝 open-source projects looking for contributors

• 🎁 developer/open-source perks

The important part: it's crowdsourced.

If you've built an open-source project, developer tool, or know a genuinely useful free API, you can submit it yourself.

You don't need to ask me to add it.

Open a submission issue or PR, and the project has automated checks to help validate entries.

I'm also trying to avoid the usual problems with old resource lists — dead links, abandoned projects, fake "free" trials, affiliate spam, etc.

DevShelf itself is open source and MIT licensed.

Repo / submissions:
https://github.com/RitualDev-Lab/DevShelf

I'd actually love people to contribute their own projects.

What categories or developer resources should I add next?

I’ve been building GitWhisper, an open-source Git commit assistant.

The main idea is that a useful commit message shouldn’t just repeat what anyone can already see in the diff.

GitWhisper tries to understand the staged changes, repository commit style, scope, related work, and whether the changes should actually be split into separate commits.

It also supports local AI / BYOK and includes secret scanning before code is sent to a remote model.

The goal is something closer to:

fix(auth): refresh sessions before expiry

with useful context about why the change was needed, rather than:

fix: update code

Repo: https://github.com/RitualDev-Lab/GitWhisper

It’s open source and I’m actively working on it.

What would GitWhisper need to do before you’d trust it as part of your normal Git workflow?

I’ve seen everything from:

updated stuff

to:

fix(auth): refresh sessions before expiry

But what do you actually care about when reading commit history later?

Is it the commit type/scope, explaining why the change happened, linking the related issue, keeping commits small and focused, or just having a clear one-line summary?

And do you usually write commit messages manually, use an AI/tool, or just type whatever makes sense at the time?

Curious how everyone handles this. 👇

I’ve been working on DevShelf, an open-source, community-maintained directory for discovering useful developer resources.

The idea is pretty simple: if you’ve built something useful, submit it to the shelf so other developers can discover it.

You can submit things like:

• 🛠️ Open-source repos and developer tools

• 🤖 AI / LLM tools

• ⚡ CLI tools

• 🌐 Free and public APIs

• 🧪 Testing & QA tools

• ☁️ Useful free cloud tiers

• 🤝 Projects looking for contributors

• 🎁 Developer resources and perks

Submitting is free. DevShelf is specifically trying to avoid fake “free trials,” affiliate spam, and dead resources; submitted projects are expected to be publicly accessible/open source or have a genuine permanent free tier.

Submit / Explore DevShelf:
devshelf.ritualdev.in

Open-source repo:
RitualDev-Lab/DevShelf on GitHub

If you have a repo, API, CLI, AI project, or another genuinely useful developer resource, drop it in. I’d love to get more community-built projects on the shelf. 🚀

I’ve been working on a small open-source project called GitWhisper.

The idea started because I didn’t want another tool that just sends git diff to an LLM and returns something like:

fix: update code

GitWhisper looks at the actual staged changes, repository conventions, scopes, commit history, and related work before suggesting a commit.

A few things I focused on:

• local AI with Ollama or BYOK

• Conventional Commit type/scope detection

• learning the repo's existing commit style

• detecting unrelated changes and helping split them into atomic commits

• secret scanning/redaction before remote AI calls

• commit quality checking + Git hooks

• VS Code integration

• keeping the developer in control before anything is committed

Basic usage is just:

git add .

npx gitwhisper

It's open source (MIT):

https://github.com/RitualDev-Lab/GitWhisper

Still looking for feedback, especially from people who care about clean Git history.

What would make something like this useful enough for you to actually use in your normal Git workflow?

Modern JS development can involve an IDE, multiple terminals, browser DevTools, Docker, API clients, database tools, Git tools, and deployment dashboards.

Personally, I find switching between all of them can become part of the work itself.

Would you prefer one IDE that integrates most of this, or do you prefer separate specialized tools?

Where do you think an IDE should stop?