One could say they are streets behind.
hornywarthogfart
joined 6 months ago
Looks promising although I think it's unfortunate they based this on VSCode instead of the Code - OSS repository that VSCode itself is based on. VSCode is Code - OSS but with added Microsoft tooling. The vast majority of users wouldn't benefit from the MS additions with the exception of the extension store but you can enable the official MS extension store in Code - OSS as well.
Will be interesting to see how this progresses as they get more adoption.
Giving them your settings provides them (and anyone they sell it to) with more insight about you and how you use their software. This is valuable data and it kind of drives me crazy that articles refer to this as a free option. It isn't free. It's Microsoft pricing something low enough to get sales from middle of the road people, while being high enough that a lot of users opt into the backup option. It's a poorly veiled attempt to extract more of you for their training, their ad sales, or their targeted sales.
Honest answer? It makes it easy to release an application cross platform.
Personal / hot-take answer? Because we are human and our drive for mediocrity is astounding...especially when it can save a few bucks. Why make something good when you can make something less good faster and cheaper? That should be Electron's slogan.
This person obviously has their own way of doing things that works for them and that's great. Some of his views are patently absurd though. This is mostly commenting on his reasons against using a forge and not a comment that he should do something differently.
Trust
100% fair and I think this is the main take-away from the blog post. If you don't trust something, don't use it. Full stop, the post could have ended there and been fine. But then it goes on to say:
You get a workflow imposed on you
You mean like forcing people to use email to submit pull requests to your self-hosted git repos? It doesn't matter what you are doing, if you are working on an open source project you are going to have workflow limitations. This is arguing a fallacy.
In particular, your project automatically gets a bug tracker – and you don’t get a choice about what bug tracker to use, or what it looks like. If you use Gitlab, you’re using the Gitlab bug tracker. The same goes for the pull request / merge request system.
Nothing is forcing you to use these features so just don't use them. Plenty of teams use 3rd party tools but host their code in a forge site. Having options available to you automatically is not the same thing as being forced to use them. If it was, JIRA wouldn't exist because everyone would use github/gitlab/whatever's built-in issue tracking and project management.
The majority of the post comes across as someone who just doesn't like the forge sites and aside from the trust aspect, then spent a bunch of effort trying to create associations and limitations between things that don't exist.
Trust is 100% the main reason not to use a forge site and all the other things cited are superfluous and/or very subjective.
view more: next ›
I get what you are saying and this is definitely a factor but I think the bigger influencer was mobile adoption. As soon as smartphones took off it was inevitable that we would see a surge in cross platform frameworks/libraries.
The fact we tackled this problem by shifting everything to web apps was also inevitable given the more simplistic deployment requirements and maintenance costs of a website vs native application.
I feel like I am shouting to the void when I talk about performance of modern software being unbelievably bad.