JSONSchema covers a lot of various schema needs and YAML is something a lot of developers are comfortable with. I know both of those technologies are not popular here in HN but YAML type-checked and editor-autocomplete-enabled using JSONSchema is a solid choice for configurations in my opinion.
Jsonschema is still json and yaml is absolutely not comfortable to work with. It’s only enough for simple configs. As soon as you have the urge to use a template you should replace it with something else.
> We offer plugins and extensions for IntelliJ, Visual Studio Code and Neovim, with Language Server Protocol support coming soon. Why? Why would they not have just done the language server first (or only)? All of those have built-in support for it, so separate implementations wouldn't have been necessary; that's the point . I just don't understand why you'd make that decision on a greenfield project today, especially…
> I just don't understand why you'd make that decision on a greenfield project today, especially if LSP support is planned at all? How about if the LSP doesn't cut it for the kind of they IDE support they want to offer?
Well I suppose that's what I'm asking, is that the case? I'm not aware of other projects that have a separate plug-in due to LSP shortcomings, so just interested if there is something they're doing that's not possible/won't be in the LSP one.
I'm sorry, can someone explain why one would want to translate from one data description language to another (Pkl -> JSON, or whatever)? Why not just write JSON (or whatever) to begin with?
Writing raw JSON is very error prone and you have to repeat yourself a lot. I think everyone who has worked with it has had some surprises, I certainly have.
Similar to why do we write Python instead of assembly, or why do relational databases typically have things like datatypes and constraints?
> We offer plugins and extensions for IntelliJ, Visual Studio Code and Neovim, with Language Server Protocol support coming soon. Why? Why would they not have just done the language server first (or only)? All of those have built-in support for it, so separate implementations wouldn't have been necessary; that's the point . I just don't understand why you'd make that decision on a greenfield project today, especially…
I can imagine the answer if I were in their shoes. Say I already have something working as a plugin (or know how to make plugins vs. learning from scratch about implementing LSP), I'd rather have this out there as soon as possible and add more tooling/language support in subsequent releases.
If it was just one I would have assumed the same, but Intellij, VSCode, and Neovim..?
> We offer plugins and extensions for IntelliJ, Visual Studio Code and Neovim, with Language Server Protocol support coming soon. Why? Why would they not have just done the language server first (or only)? All of those have built-in support for it, so separate implementations wouldn't have been necessary; that's the point . I just don't understand why you'd make that decision on a greenfield project today, especially…
Why assume it's a greenfield project? I would think most open source software that comes out of companies have lived internally for a while before going public?
Is this a joke? Why? We have so many usable formats already. Every language can do JSON. What problem does this solve? Or is this another Apple solution to a problem that doesn't exist?
I'm sorry, can someone explain why one would want to translate from one data description language to another (Pkl -> JSON, or whatever)? Why not just write JSON (or whatever) to begin with?
The amount of problems I've had with JSON in my career makes me think almost anything could be better than it. There's so many weird edge cases in the JSON spec that you can hit that it just becomes endless levels of hair pulling.
> We offer plugins and extensions for IntelliJ, Visual Studio Code and Neovim, with Language Server Protocol support coming soon. Why? Why would they not have just done the language server first (or only)? All of those have built-in support for it, so separate implementations wouldn't have been necessary; that's the point . I just don't understand why you'd make that decision on a greenfield project today, especially…
have you worked with ide native extensions?
while LSP is useful, his expressiveness and power and integration is limited.