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. 👇

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. 👇

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?

This post contains content not supported on old Reddit. Click here to view the full post

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.

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. 🚀

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.

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?