flui
flui copied to clipboard
Why a custom language ?
Self-explicit issue :
Why not using yaml instead of a custom language?
Stack:
alignment: Alignment(0, 0.5)
children:
- Positionned.fill:
child:
Container:
color: Colors.red
- Container:
height: 50
with: 50
yaml is already supported by most IDE and it should be pretty straightforward to add auto-complete for them too.
Or html too, that would work.
@rrousselGit
Sorry for taking so long. I must have missed the email at some point.
The main reasoning behind the custom language approach was two-fold. First, I wanted the UI language to map as closely as possible to the Dart syntax while eliminating extraneous punctuation. The second reasoning was that it was mostly just for my own benefit as a learning experience to write a custom interpreter.
For practical purposes, YAML itself would likely be plenty sufficient for FLUI's needs. One thing, though, that I found to be lacking in YAML syntax was the ability to define multiple properties on a single line. So, for example, where YAML would look like this:
Container:
width: 50
height: 50
child:
...
the custom language could do this:
Container .width 50, .height 50:
.child:
...
It's certainly a case of personal preference, though, and just using YAML would simplify a lot of the implementation process. One thing I want to avoid, though, is resorting to a convoluted naming scheme to cover edge cases (thus hurting the benefit of readability) - if it's feasible, I'd much rather have those kinds of things be supported by the language itself.
(On a more personal note, I'd like to avoid using an XML/HTML style approach. Just from my experience with Android development, XML-defined UI can easily get bloated and verbose.)
I see. The main reason for this issue is that it would potentially require a big amount of work for IDEs support
Things such as syntax highlighting, auto-completion and validations can be hard.
For sure, I didn't have any short term goals of implementing FLUI in anything other than VS Code for that very reason, though I'd imagine that the bulk of the work in other IDEs would be in implementing those features, not necessarily in adding support for the language itself.
The interpreter/tokenizer is complete in C#, and I'm nearly finished with a Typescript version as well. Admittedly I don't have any experience in writing plugins for IDEs like Android Studio/IntelliJ, but I wouldn't think that translating the interpreter itself would be that much work compared to implementing everything else involved with intellisense, autocompletion, highlighting, etc.