Show HN: React Oxide: minimal in-browser code editor with tabs and files

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • Appwrite - The Open Source Firebase alternative introduces iOS support
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • Scout APM - Less time debugging, more time building
  • JetBrains - Developer Ecosystem Survey 2022
  • reactoxide

    The EventEmitter pattern seems interesting! I can't say I've wrapped my head around it enough to weigh the benefits and drawbacks. I would point out a few things after a quick look:

    * It looks like you're creating an emitter wrapper around an EventEmitter instance, freezing it, then exporting the instance rather than the frozen wrapper[0]. I see .on() and .off() are wrapped here, while the project appears to use .addListener() and .removeListener() instead.

    * As a typescript project, I would recommend using typed-emitter[1]. Not only does it ensure you're only emitting recognized events, it ensures that the type of the payload is correct for the corresponding event. Currently, your typed handlers are coercing from `any` as far as your IDE is concerned, rendering it unable to help prevent you from mistakes.

    * Instead of plumbing an emitter prop everywhere, even through components that don't interact with it directly, this looks like a better fit for the Context pattern to create the global emitter instance in a top-level context provider, then getting a reference to the emitter via useContext[2].




  • Monaco Editor

    A browser based code editor

    Hi folks this is React Oxide.

    It's a minimal code editor that runs in a browser. MIT licensed, code at:

    I wrote React Oxide because I needed a simple code editor but couldn't find something that included editor, tabs, a file tree and file management.

    You can see a YouTube demo at

    You can see a live demo at

    It use the Microsoft Monaco editor

    It's written in TypeScript.

    The React code is written in a style I call "Event driven React", which means inter component communication is done via event emitters rather than using global or lifted state. So state is almost entirely managed at a component level. I did this because I find state to make React applications complex and hard to debug, whereas this event driven approach I find easier to understand and write. I would not be surprised if someone comes along and tells me why it's a bad idea, but so far it seems to work - perhaps someone can let me know what the drawbacks are of such an approach.

  • Appwrite

    Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!

  • effector-react

    Business logic with ease ☄️

    The issue with using eventemitter for state coordination is that when the UI grows into complexity you run into race conditions where some component isn't showing the right data because it got mounted too late or something somewhere up the hierarchy changed a key and the component got recreated and its state got lost.

    I guess as long as long as the component hierarchy fits in your head, it is likely straightforward to reason about all the event interactions.

    The lifted state model ala redux (and similar alternatives) doesn't suffer from this problem.

    I personally prefer effector [1] these days because it combines the convenience of event emitter with multiple stores and you usually find yourself thinking much less about what changed the store causing my component to rerender much less often.


NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts