This American is all for banning facial recognition, with stiff penalties for the person in charge of any company or agency who breaks this ban. The US is not China and the government exists to serve and protect its citizens. At least in theory.
> According to a February 2022 report by the Mercator Institute for China Studies (MERICS), a social credit "score" is a myth as there is "no score that dictates citizen's place in society"
https://en.wikipedia.org/wiki/Social_Credit_System
If you have time for the project, you have time to learn a proper setup that every company for the past 15+ years has used.
SSR is quite frankly a performance myth if you distribute your frontend on a CDN. Ultimately your cloud functions reach out to your database, that is centrally located... SEO work well without SSR for the most part.
> Ultimately your cloud functions reach out to your database, that is centrally located...
A big difference is that your code running in the datacenter should always be well connected to the network. The user running your code out in the middle of nowhere teetering on the edge of available mobile coverage... Not so much. SSR means the user can begin after one round trip instead of, at bare minimum, two (and more realistically at least three – HTML, JavaScript, and data), which becomes significant as latency rises.
Although I would agree that the cases where you actually need that are not as common as we like to think, and even where justified a lot of developers are bound to screw it up such that the app isn't usable without multiple round-trips anyway. It is certainly something you should think long and hard about. It is not tradeoff-free.
As far as I’m concerned, SSR is completely over-hyped and adds a ton of complexity to your project. All these search indexers are all running headless chrome anyway so the SEO argument is largely false now.
Running vite and deploying a fully static site that interacts with an API is, to me, vastly simpler to reason about than a blackbox react framework (next.js) sitting on top of a black box rendering library (react).
Having a “backend for your frontend” is pure overhead for most projects. I’ve been building on the FE for a decade and have only needed SSR once and certainly never needed some hybrid static/dynamic/islands setup.
If you need SSR, you need it, but I find SPAs to be vastly superior in terms of dev speed and overall performance of an app once the JS has loaded.
Not always true. I've coached people to stay before and they are still at the company. Sometimes they have concerns that actually could be fixed from management. People are complex and have many different reasons for wanting to leave, some fixable some not.
I was just at a developer conference and was amazed at how many people used Auth0 and OAuth interchangeably. They've done a super job of capturing mindshare, and have a great brand.
When you click the button to make a repo private, you first have to acknowledge that you will lose all of your stars among other things. Losing stars is literally the first bullet point. Then you have to type the repo name as acknowledgement before you can make private. PR stunt?
Make private:
Hide this repository from the public.
You will permanently lose:
All stars and watchers of this repository.
All pages published from this repository.
Dependency graph will remain enabled. Leaving them enabled grants us permission to perform read-only analysis on this repository.
Also of interest for those who care - you can contact GitHub support and they will remove the link to the repository you forked from.
This can be useful if you're actively developing a project that was abandoned, as it makes it so default PRs are against your master instead of against the origin repository.
Even worse than that - you have to go into the "danger zone" on GitHub, and then there's a big banner that says "Warning: Potentially destructive operation" and also the gates you mentioned.
They bypassed numerous sanity checks and then clicked the button that did exactly what it told them it would do, and now they're sad.
Do stars on GitHub _do_ anything? Usually I'm a bit put off by any kind of internet point begging, but I'm curious what the impact of losing them is. Is it mostly a signal of "I like this"?
Discarding self-validation social media-ing, stars xlate into discoverability and ranking algo positions for the starred and bookmarks for the starrer.
Well, sure. It's not like a human is on the other end checking the final "ok" before throttling somebody's data speed because they have exceeded some threshold.
Anecdotally I've found Github much cleaner-looking, much faster and more usable than Gitlab. Github was never opensource, and I think people used it for all of the above. I'd be surprised if the recent acquisition changes that.
I feel like part of this minority. I find GitLab's UI less clean and more difficult to process, and miss the social interaction features like the feed.
I preferred GitHub's UI because it was cleaner and much faster to load.
I'm part of it too. Some years ago I was looking for an alternative to GitHub, with free private repositories for some personal projects I wanted to keep private. After a few weeks on GitLab I ended up moving to BitBucket because it was generally faster to use
I think if Github does one or two huge updates that are really well received post-acquisition, preferably the kind of updates only possible with a tech giant behind you, they will secure their position for a long time. For most users Github still has the best product - how people are forgetting that is beyond me.
"preferably the kind of updates only possible with a tech giant behind you"
What kinds of these? Its never been the case that 25% more engineers means 25% more progress and github is a mature product made by a company that already employees a signifiant staff.
The logical thing would be not to piss off the existing users and use github to add value to existing Microsoft properties. So some new integration with Microsoft things?
Expanding the Github Education package, integrating Github offerings with the Spark program, applying Bing search expertise to Github code search, creating a more flexible pricing model for hobbyist users, expanding their free offering, creating better Desktop/mobile applications for Github services (better the the open source ones currently available at least).
Probably because Bitbucket is a terrible product. It has the worst interface of the group, and less-than-minimal support for pull requests (comments disappear when unrelated changes are made, aren’t easy to browse, aren’t related to a review; only options are approve and permanently close; code expansion doesn’t work past a certain point, and doesn’t work at all if the pull request comes from a repo you don’t have access to even though you could just merge the pull request and get it).
Also required users making private forks of paid-for organization private repos to pay again to give access to all team members at once last time I used it, but I guess that’s not relevant for open-source migration.
I would argue that Atlassian has better rapport with engineering manager types. Their products integrate and bundle quite nicely which is compelling for many organizations. As a dev, I'm not a fan of their UX but I've known quite a few PMs that are JIRA masters and love the fully integrated solutions Atlassian offers.
Does Atlassian have better rapport with the businessy set that often makes purchasing decisions? Yes.
Better rapport with developers? Probably not.
(and, FWIW, we use Bitbucket/Jira and honestly I'm fine with them - their updates just tend to be full of the annoying things a bad PHB would love and light on the things developers care about)
Doubt it, in the long run. I also question the move from one VC-backed company to another unless you're only using their self hosted options (though I guess being open source is better).
