>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.
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
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?
> 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.
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
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.
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.
I wanted to try Easel but there were no instructions how. This is how I got it running: