You can get away with very fast, very maintainable front-end code that doesn't need any special frameworks when you say no to modern tastes and features. More websites should really consider doing so.
One of the things that breaks my heart just a little is visiting these sites that load in 30ms and thinking that the Internet of 2019 could be largely like this and how amazing that would feel. Sure, there's lots of complex features we cherish having online, but those could all be hidden behind the main pages that are dead simple. Makes me think about how google.com is the gateway to a massive conglomerate of capability, web apps, features, etc. but the main page itself loads almost instantly.
That's also why google.com was originally so simple, in stark contrast to their competitors of the day.
Where are the PBs of javascript, the YBs of uncompressed images in 128x320 res?
Clearly they've messed up their CDN and we're missing content.
Is that in a single location? If so, then it's not really impressive. A good website loads fast even when the client is on the other side of the globe.
"Initial request to clickability" is definitely longer than it used to be.
I also remember when you could register without an email.
My eyes are bleeding
Maybe there is a relation?
I assume it doesn't scale extremely easily but seems to work good enough for now.
YesSQL scales just fine to enterprises like VCS repo hosting. All you have to do is shard correctly (along the lines where you least need the power of SQL, preferably).
You can write a client-side application and distribute it through some CDN (like Netlify) and have no administration duties or server cost. However, your app will end up not working without JS (and your tech stack could possibly be a mess, depending on your choices). Or you can generate pages on the server which requires you to have, well, a server.
Both approaches have benefits and drawbacks.
We're in way too deep here.
Anyway, few hundred dollars added or subtracted doesn't really change the point. This is a fairly cheap operation given what it provides.
Refugees... from a third party service... because things changed since they began there
Some other third party service welcomes them, but has bad front end...
SOLUTION:
1. Mercurial and Git are decentralized! They have been designed to be so. Make your back end decentralized also. Why rely on a centralized site?
2. We used to run front-end programs on our computers! What a concept. We thought desktop computers were far better than mainframes and “fat” clients were far better than “thin” ones. Now we are all back to mainframes.
3. End to end encryption! I mean wow half of all humanity has their accounts in an epic database of 3-4 billion people from many breaches. All their private information is now out there. And you trust GitHub, Facebook or whoever to host your group’s private data?
MaidSAFE, MetaMask and other projects do 1,2,3. You should be in control of your keychains. We have plenty of desktop apps for managing eg git. Why let GitHub do it?
At the very least, run GitLab on your own in-house servers. But there are other alternatives.
And frankly, think about the speed and environmental impact of shipping all those bits to Google where you are “renting” Google Docs / Drive software to collaborate on something. You can have a lightning fast network in the Brazilian Favelas or a village in Namibia. Dating sites, ZocDoc, OpenTable, GrubHub can all be local open source apps running on local mesh networks. But nooo, we need project loon to send our signal to california in order to talk to our neighbor or coordinate dinner plans. And in Kashmir, etc. the government can simply turn off our internet and suddenly BAM — can’t even stock drugs locally for people??
https://www.nytimes.com/2019/08/14/technology/india-kashmir-...
Further, it's a completely open source product which strongly encourages self-hosting; the main reason to subscribe to the hosted instance is to give money to the dev.
The big appeal for moving to mercurial for us was better merging than svn. Our team worked a certain way already, the tool handle this workflow and that's one of the reasons we chose mercurial. Decentralized was just nice for full backups in a lot of ways.
Server-side bottlenecks are more often than not database reads/writes and other IO. And the few CPU-intensive operations can be delegated to libraries written in C.
Pure Python is slow for CPU-intensive tasks, but that doesn't mean that a Python webserver is necessarily slow.
As an example, https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht takes 600-800 ms to generate, and it's probably heavily cached already. What will happen when they get more users? The site will be unbearably slow, unless the guy starts spending thousands in servers.
800ms is a reasonable response time, and if they scale up according to their userbase, they will hopefully maintain that time.
(Also, we don't know how much of that 800ms is Python vs. IO)
https://github.com/pallets/jinja
0% C
Also 800 ms is NOT a reasonable response time to generate what basically is a bunch of text, that is absurd, but I guess this is the baseline in 2019.
I trust all IO is cached. The author can confirm it. This is just how slow Python is.
[0] https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht/bl...
$ curl -s https://sourcehut.org/|egrep 'meta.*gen'
<meta name="generator" content="Hugo 0.57.2" />
https://git.sr.ht/~sircmpwn/meta.sr.ht/tree/master/metasrht
https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht
https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht
edit: It is using flask according to this blog.
https://drewdevault.com/2019/01/30/Why-I-built-sr.ht-with-Fl...
There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future.