If you’re asking about specific names of features, its just the ones seen in that video clip. It seems like a pattern of very not-modular-ness.
If you’re asking why that pattern is concerning as an end user: Zed claims to be “a lightweight text editor”. But hardcoded support for a particular javascript library, as well as hardcoded support for a particular formatter, feels a lot more like a opinionated IDE packed with features designed for the specific workflows of the creators. Even if there’s no runtime cost, there is a technical cost for open source contributors. These little not-modular things can really bloat the codebase and make it hard to contribute.
More importantly, if Zed does add plugin support in the future, its going to require a major code refactor. Which makes forks and outside contributions especially hard.
From a lock-in perspetive: if something better than tailwind comes out, and we were daily driving Sublime 3 with no extensions, its no big deal to switch to the new thing. There wasn’t any hidden favoritism to begin with. But in Zed, not only will it feel bad to use the unsupported new thing, but also the team behind the-new-thing can’t realistically fork and add support either. They just have to hope the Zed devs decide to support it.
If their website said it was a fast low-overhead opinionated IDE I’d be fine because I’d know the kind of lock-in I was getting into.
Can you be more specific on these concerning hardcoded features?
If you’re asking about specific names of features, its just the ones seen in that video clip. It seems like a pattern of very not-modular-ness.
If you’re asking why that pattern is concerning as an end user: Zed claims to be “a lightweight text editor”. But hardcoded support for a particular javascript library, as well as hardcoded support for a particular formatter, feels a lot more like a opinionated IDE packed with features designed for the specific workflows of the creators. Even if there’s no runtime cost, there is a technical cost for open source contributors. These little not-modular things can really bloat the codebase and make it hard to contribute.
More importantly, if Zed does add plugin support in the future, its going to require a major code refactor. Which makes forks and outside contributions especially hard.
From a lock-in perspetive: if something better than tailwind comes out, and we were daily driving Sublime 3 with no extensions, its no big deal to switch to the new thing. There wasn’t any hidden favoritism to begin with. But in Zed, not only will it feel bad to use the unsupported new thing, but also the team behind the-new-thing can’t realistically fork and add support either. They just have to hope the Zed devs decide to support it.
If their website said it was a fast low-overhead opinionated IDE I’d be fine because I’d know the kind of lock-in I was getting into.