this post was submitted on 30 Jan 2024
261 points (95.5% liked)
Open Source
31408 readers
14 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Lapse is going the extensions-for-features route, cross platform from the start, is more buggy atm, slower progress (doesn't have 3 dedicated experienced devs) but is more accepting of community support.
Zed, similar goals and rust backend, probably has some monetization goals (eventual offering of live sharing code service), and Zed isn't afraid to hardcode features. Like... very hard hardcoded features, to the point that I'm kinda concerned about it. This 5min clip of Theo looking over the source code shows it pretty well https://www.youtube.com/watch?v=ZOYp6-k9HhE&t=1533
The Atom/Zed devs write the most well-documented code I've ever read. Clear variable names, perfect comment-explainations when needed, etc. I wish they would join up with Lapse.
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.