make frontend less patronizing #4804
Replies: 1 comment
-
Thanks for the feedback! As it happens, we have completely scrapped the frontend recently to incorporate AI into it, and the frontend we had was not particularly conducive to it. We did think about a VSCode extension and even experimented with one for a few weeks, but we didn't like that we lost the instant start. We may add a VSCode extension at a later date though in addition to the other parts - we do like that idea. We have some speculative designs for this: https://www.notion.so/darklang/Speculative-designs-141fbac2391f45de82082b17af80a56b. Please feel free to create your own whether textual or visual or whatever - am interested to see your thoughts on it. |
Beta Was this translation helpful? Give feedback.
-
I really like dark for the heavy lifting it does for me.
I am not sure where it places itself in terms of the NoCode alternatives out there, but I see there could be a niche for it.
Just sometimes, dark seems to "try too much" in the frontend. Then it does not really feel usable unless you really know what you do.
Especially the idea to make it "canvas style" makes it near impossible to create a maintainable "good enough" backend.
I'll explain:
Everytime I come back to the backend in dark I need to read almost everything. Dark makes it hard to document the APIs for my future self or structure it in a way which requires little documentation.
API devs often start with the description of what their API is supposed to do.. the implementation is then secondary.
The visible dark goodies
From my naive perspective you get currently with dark:
Problems
Sidenote: The feature flags and the ideas to migrate the systems are still very alien to me, can't figure how this system is supposed to work. I saw the tutorials, but when I find the magic buttons to wrap something in them, it usually screws something up in my code. So I exclude those features from my suggestion here, as I can not really say something about them.
From my perspective this is not what is really missing to make a dark-backend usuable as main backend, but the lack of telling a story about your APIs.
Currently the custom input system to the canvases make trouble to me all the time (copy paste not working, delete not working, the magic menus not appearing when a non-american keyboard is used, the menu options not being selectable with the mouse, just keyboard, scroll not working on a touchscreen, zoom-in not possible, .. small errors, but they build up).
So I was thinking: All that self-developed canvas just to make some text hints appear around your functions ("traces") and to check eagerly for typing errors?
Can we do this in a lazy way, without all the reinventing a text editor?
Suggestion
I would suggest doing the whole frontend from scratch.
Each space is a folder of "dark-markdown" files.
The markdown can contain code sections like usual. But when the code sections is "dark", it get's interpreted live on the dark servers.
Like the markdown plugins doing syntax highlighting, but in executed remotely.
Benefits
This way I could tell a story and make things "live" at the same time. My "reading code"-experience could become something like "hey these are all parts we coded together in that hackathon" or "this is all login and user management stuff" (and not "here are all the databases. Oh and over there are functions, make sure to read the code" as it is currently enforced. Not judging, I saw that we went a long way even to arrive here).
Implementation
I could imagine a PoC would simply be self-written cheap ass html page using some markdown rendering lib and some tree widgets for listing the different files.
A more sophisticated solution could come in the form of a VS Code extension for dark-markdown files.
The dark webapp would then simply boil down to https://github.com/coder/code-server being hosted by dark (and having the extension pre-installed).
This would solve code suggestions, formatting and all kind of text input problems. And it would mean going into an environment, our users know already or even are already in: the IDE.
positive side effect: clear business position
For the business side of dark it would mean it would try to establish it as code-near alternative to NoCode. Imo this could also be a huge win in contrast to its current positioning: if I want "no setup" I will currently walk to NoCode competitors (although I like to read code as a dev and dislike the platform approaches NoCode wants to lock me into).
Thank you Paul for reading all this and considering trimming the frontend to just the necessary parts.
Beta Was this translation helpful? Give feedback.
All reactions