Hacker News Reader

Comment by unwind | Hacker News Reader

That sounds awesome for VS Code users in general, but I guess it's sad news for the independent developer (CoenraadS) who made the pair colorization extension popular and famous.

With the editor's native performance 10,000 times better, I suepect the number of installs of their extension will plummet.

It's hard to compete with 1st party powers, as all the hoopla around app stores (and before that, the famous "Embrace, extend & extinguish" [1] strategy) show all the time.

That said, I'm not saying it's a hostile move, it's just ... interesting.

[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

View on HN

The original developer doesn't sound too worried and seems to have collaborated on the feature: https://github.com/CoenraadS/Bracket-Pair-Colorizer-2/issues...

Plus it helps him getting rid of 399 open issues.

That's great, I did not research this beyond reading (most of, it got pretty technical!) the article.

In retrospect I guess I'm a bit disturbed that I even think about these things in terms of fame/popularity, when it should be solely about tool capabilities and power for its users. :) Shame on me, back to reading FSF doctrine.

I don't think it's wrong to assume that fame/popularity plays a role in open source. Open source developers have to get motivation from somewhere. Taking some pride in developing something popular is fine in my opinion.

That being said, my first impression from the article was quite the opposite of yours. I thought it was great news for CoenraadS. He developed something so useful, that it was integrated into the core. That's impressive! The plugin is obsolete now, but in this case it looks like "mission accomplished".

Of course this move would look different in other app/extension ecosystems where extensions are monetized and/or not open source.

Author of the blog post here.

We openly discussed various approaches with CoenraadS and other extension authors here: https://github.com/microsoft/vscode/issues/128465#issuecomme...

Thanks for your awesome work! Can't wait to try it.

Quoting CoenraadS:

> Author of Bracket Pair Colorizer here.

> I follow this thread with interest, my extension is something that grew a bit out of control, and I grew tired of maintaining it.

> If there are some quick wins, I can still apply them, but I think my extension is so hacky it is easier to do 1.b or 1.c

Seems CoenraadS is completely in favor of the native implementation (and probably could have been called out in the blog post as few people will find this context).

Isn't that kinda what you want though?

- Make an extension to solve a problem that probably should have been in the core

- Product owners notice and realise it should be in core

- Work with extension developers to get it in to core

- No longer need to work on extension

Sounds ideal for anyone who writes an extension to enhance their experience rather than because they find joy in writing and maintaining the extension.

What? If the independent developer didn't want his technology to be used, he would have patented it or made it closed source. This is not what EEE is about.

So Microsoft can never-ever integrate any feature implemented in any popular extension in VSCode, which is also mostly open source and free (in both meanings) I might add (except for some small things).

That's just silly.

I can see your viewpoint so I'm not sure why you are getting voted down.

> I follow this thread with interest, my extension is something that grew a bit out of control, and I grew tired of maintaining it.

The quote above is from the maintainer. Looks like he is happy to let it go!

Quote source: https://github.com/microsoft/vscode/issues/128465#issuecomme...

Reply on news.ycombinator.com