Easel Turns One One year of building my own IDE in Clojure | Hacker News Reader

Easel Turns One One year of building my own IDE in Clojure

blog.phronemophobic.com

183 pointstodsacerdoti17 comments

This sounds very close to my dream IDE, I've always wanted to build a smalltalk + emacs like editor/ide in Clojure but never got around to it.

I wanted to try Easel but there were no instructions how. This is how I got it running:

  git clone git@github.com:phronmophobic/easel.git
  clj -X:deps prep
  clj
  # now in repl
  => ((requiring-resolve 'com.phronemophobic.easel/run))

Amazing project!

>While the JVM solves lots of hard problems, it has one major weakness, the UI libraries provided by the JVM (Swing and JavaFX) are clunky and dated.

I also feel this; it's what puts me off writing GUI apps in Clojure. I have hope that natively compiled Clojure implementations like Jank that could interact with C or C++ libraries could help with this.

what specifically did you have issues with?

i made a GUI with cljfx which uses JavaFX and I didnt really hit any issues (save for i have one bug on startup that ive had trouble ironing out). The app is snappy and feels as native as anything else

Ended with a very modular functional GUI program

the only thing i wasnt super happy about is that i couldnt package it as a simple .bin/.exe bc the jpackage system forces you into making an installer/application (its been a few years since, so its possible theres a graal native solution now)

i highly recommend cljfx. Its the opposite of clunky

Same. I wish Webview would work with GraalVM native compilation.

tonsky seems to be chugging along with his humbleui project

https://github.com/humbleui/humbleui

Most of the work (and the recent updates) seem to be in the two main subcomponents

https://github.com/HumbleUI/JWM

https://github.com/HumbleUI/Skija

Excellent work. Now please partner with a software-focused UI/UX designer. To make a great product it takes a village.

Will do!

Awesome work! I like the idea of being able to quickly make little tools in your IDE.

Coincidentally, lately I have been thinking of making an IDE using something like Theia or CodeMirror but am holding off because of time for my other projects.

The words data and data oriented are thrown around a lot in the article. Can someone explain what is meant, exactly, and why existing IDEs miss the mark?

Data oriented in clojure slang means modeling things in data structures like hashmaps and clojure sets as opposed to defining classes and types. The language encourages you to do it and provides a lot of built-in functions to work with them.

So it must have tools save, manipulate and visualize conveniently (pretty printing, folding etc) the values of vars that contain nested maps, sequences, sets, etc.

Existing clojure IDEs like CIDER for emacs or Calva for VSCode do that too, and it is a must have to have a nice experience with the language

The best description of what I mean by data is https://www.infoq.com/presentations/Value-Values/.

> why existing IDEs miss the mark? There are definitely lots of IDEs that do cool things, but are missing one or more items from my wish list.

With respect to data orientation, most IDEs don't represent information as immutable data. If all internal state uses immutable data, it's much easier and safer to share. If everything is mutable, then sharing data is hard, which why most IDEs don't have pervasive sharing. As an example of an IDE that does provide access to data pervasively, but makes very different trade-offs than Easel, see https://gtoolkit.com/.

Using an IDE where all the tools take data and share data has dramatically changed my workflow. You can sort of get this feeling when you pipe together a bunch of shell commands `find ... | grep ... | tee ... | nc ... | etc...`. However, I think 1) sharing data rather than strings and 2) having a 2D graphical user interface is a big upgrade from piping shell commands.

This is really cool, but begs the question: is the ideal IDE actually just a window manager with strong component coupling?

This is what I keep coming back to when I am building a little tui manager for my coding assistants + terminal + git worktree manager.

I keep telling myself that if everyone just used tmux or a good emulator they could manage the tabs and layouts, but then I tell myself I just want this to be a tiling window manager as an distraction free OS for development, give me nothing but a terminal and an assistant.

Thanks for the write up OP, I've been going back and forth on whether or not I want to build something just for myself or spend time doing it for potentially other use cases. I keep coming back to that I need to dog food the shit out of this before I show it to anyone.

Injecteur Dépendance Environnement

Where tools are dependencies and the system composes them together to create a sum much greater than the parts.

I did consider that. I think it's possible, but there are a few challenges:

- It's much harder for components in separate processes to share data efficiently

- Window managers tend to be OS dependent. I want something that is cross-platform

- Coordinating components in separate, asynchronous processes is hard

- Working with OS window APIs is more annoying than writing a layout library

A bunch of this stuff is already there in Windows and in Visual Studio. It has been for decades.

But it’s legacy tech. Nobody actually cares about IPC to this degree. I suspect because nobody’s mental model works to this level of abstraction and who the hell is going to waste time doing all the plumbing.

Kudos for suffering on JVM I guess. Some people have a higher pain threshold.

Ideal IDE? As long as I have a reflow oven I’m not complaining.

Hey, this is absolutely amazing

Reply on news.ycombinator.com