I thought the whole point of PWAs was that they could access user files directly, which they wouldn't be able to as a webpage inside a browser's sandbox? If that's not the case it's just a bookmark.
3. Use Facebook, Tumblr, or Mastodon for microblogging.
Twitter started requiring a login screen to view posts, but it's not the first website to do so. Pinterest and Instagram have done this for ages. We all hate it, but it's business.
I wonder why Tumblr isn't more successful than it is. It used to be a pretty well-known platform, and it's almost identical to Twitter, but while every celebrity seems to have a Twitter account, nobody seems to have a Tumblr account. Perhaps they do, they just don't tell anybody about it?
I wish Mastodon wasn't a thing. I believe federation is a terrible idea for normal computer users due to its non-obvious dangers, specially as more people will begin using Mastodon as if it were Facebook. I saw on Reddit that someone is building an open source, non-federated Reddit clone. That's what I think would have been better: an open-source, non-federated Twitter clone. Does anybody know of something like that, by the way?
> I wonder why Tumblr isn't more successful than it is. It used to be a pretty well-known platform, and it's almost identical to Twitter,
Twitter won over that and a number of other options on novelty, inertia, and notoriety, essentially. A mix of right-place-right-time, further luck, and network effects.
Tumblr did better than many alternatives, but eventually shot itself in the foot (well, was shot in the foot by its parent) when it alienated a chunk of the audience it did have by deleting a lot of content in order to appease potential advertisers.
It wasn't advertisers, it was apple, they'd been delisted from the app store, and getting rid of the NSFW material was part of the deal that apple would allow them back with.
Tumblr used to be a lot more popular, but its collapse is usually attributed to them banning NSFW content. Not everyone was posting or viewing NSFW of course, but there was enough overlap in audiences to cause a cascade which ended with nearly everyone, NSFW or not, moving to Twitter.
It's a classic Yahoo acquisition fumble, they bought it for $1.1 billion and ended up selling it on to Automattic for just $3 million post-exodus.
>The biggest selling point that seems somewhat legitimate is a bunch of these have scale to zero capability. This is pretty useful for on-demand code that is required very infrequently and for which cold-starts are a non-issue.
I don't quite understand this. You can pay for 1 physical/virtual server and have apache serve 2 different domain names, right? Can't you just drop your infrequent app there so it shares resources with, I don't know, your more regularly accessed website?
The only scenario I can imagine this would be useful is if you own zero servers or the code is incompatible with the server you do own for some reason.
Well you do understand it, enough to work out how to live without it. :P
That said there are some key things a scale to zero serverless app has that solution does not.
1. Isolation. Your infrequent function may very well be infrequent but it's execution could then impede other code executing on that box (if it's computationally or I/O intensive for instance), or expose other code on the box to security vulnerabilities.
2. Independence. Similar to above but more addressing logical segregation. Once you are sharing a server or say piggybacking on a monolith as an extra endpoint there is now a lot of conflated concerns. For instance auto-scaling algorithms etc may not work well with the sort of intermittent/infrequent execution and it would be much better living in it's own context for that reason. Other things that end up all jumbled up: Cost accounting, IaC/deployment/CI/CD, ownership, observability, etc.
Generally all of this still isn't enough to justify serverless but sometimes it could be... but in most of those cases just eating the cost of 1 replica and autoscaling on k8s is usually better.
>resources used on serverless frameworks are typically paid for by the minute (or even by the second). This means that clients only pay for the time they are actually running code. This contrasts favorably with the traditional cloud-based virtual machine, where often you end up paying for a machine that sits idle much of the time.
I'm going to ask something very stupid because I'm very ignorant but... when do you need this?
In my mind you have scenario 1: the app never runs because no users, so running it 24/7 is a waste. In this case why cloud? Pay $5 a month for a simple web host?
Scenario 2: you are hitting 100% on a server and you need a second server but that second server will only use 1% most of the time. Again, why not just upgrade the server with your web host?
Scenario 3: you have a bajillion users on peak hours and a tenth of a bajillion on other hours. I assume you would have a business model that affords you to hire someone to manage scaling your infrastructure?
How I wish they were right about .html.,, I wish we had something else by now.
Personally I'm a fan of including a post ID in the URL, e.g. /category/123/post-name. Because if you want/need to change the URL later, you can simply parse the URL to get the ID back to create redirects. A lot of sites of all scales don't implement redirects which makes me sad.
I think there was a news site acquired by Bloomberg, I forgot the name. When you visited an article in the old domain, it redirected to a landing page on Bloomberg saying it was part of Bloomberg now instead of redirecting to its new URL.
> How I wish they were right about .html.,, I wish we had something else by now.
You can thank the browser complexity moat for that. If browsers were simpler to implement someone would have started experimenting with this (markdown at least) years ago and other browsers would have picked it up.
I don't know if it's something from the old days or not, but iirc URLs have a semicolon separator (;) that would go before the ?. I have never seen it being used. I'm betting it's even less support than commas!
In the OG RFC 2396, each _path segment_ can specify parameters similar to query parameters, but using a semicolon to separate them to the main segment value instead of question mark. This has effects e.g. when calculating relative URLs. This is now obsolete, but many URL-parsing libraries have an API for that for compatibility.
Do 10x engineers get 10x the wages? Somehow I feel being exceptionally better than other engineers is just unfair to both of you and the ones worse than you. I wouldn't want to be a 10x either, I'd rather just be normal engineer.
Meta compensates 10x types very well. 3x bonus multipliers, additional equity that can range from 100k-1m+, and level increases are a huge bump to comp (https://www.levels.fyi/)
Meta compensates all SWEs very well. To suppose arguendo that 10x types exist, I don't think they're really compensated linearly 10x more than everyone else. But yeah, certainly, if you are great at your job and want to make a bunch of money, Meta is a great employer for that.
3x bonus multiplies (Redefines Expectations) are extremely uncommon. Level increases certainly help but like, L7 only makes ~3x what L5 does -- not 10x. And there are few L7s and very few L8+.
I think the most worrying thing about emulating old consoles by reverse-engineering them is that you're running out of time to test it. Say for example that the original Luigi looks blue in the hardware it was made for, but in an emulator he looks green. If there are no original NES left, you will never be able to know the emulator's code doesn't match how the NES actually worked. From that point on, the emulator experience is as canonical as it gets.
Different NES revisions actually output different colors. Plus, originally it's an RF signal, then composite. It was displayed on some CRT. It's possible to RGB mod an NES, but is that authentic? No.
The one true color of Luigi is the one that you saw as a child on a sunday afternoon in the eighties. Lost in time, like tears in rain.
It's things like this that make me think the way to make a good UI is to look at what modern UIs do and do the exact opposite.
1. No spacing.
2. Information-heavy cluttered screens.
3. No auto-save. You have to click the save button to save.
4. Colored icons. Colored interfaces. Not "tinted" a hue of black or white. Actual vibrant colors. And not just one color either! Two colors, at least.
Absolutely. I have a theory that "windows" are called "windows" because of the 3D ridges at the borders. The moment we stopped doing ridges, everything went the wrong direction.
This translucent, rounded, acrylic, material, whatever, it's just not fun. We had the technology for making glorious media players in the year 2000. Where did our technology go?
I'm on linux right now and I checked a bunch of desktop environments and every single one I checked the themes for (the theme browser sucks, by the way) what I see is dark theme with a blue tint, light theme with a blue tint, dark theme with a green tint, light theme with a green tint. A Windows 95, XP, and 7 clone. And that's it?
It just blows my mind. I don't know if it's because the theme browser sucks (the websites to browse the themes also suck, by the way), but I can not find one theme like XP but not XP. I'm left wondering where did all those people who made so many beautiful, glorious, amazing WinAmp themes go to. Did they become extinct? Are the theming APIs too limited today to go all out? Is the technology not there yet to have border-image in your windows borders?
This is just so depressing. I'm hoping the pendulum swings back in the next 10-20 years, and hopefully I'm still alive by then to see some cooler GUIs.
I remember modifying the UI of Virtual DJ 6 for friends that wanted their logo on it. It was all bitmaps. And I guess the different skins were 3D renders on existing DJ decks. But they were beautiful, although there was a period there were some issue when laptops were moving to a wider ratio.
Sounds kind of hard to use on mobile, which is indisputably a popular set of platforms.
No need to throw the baby out with the bathwater. Big (resizable) UI elements with poke-ability are fine. Auto-saving can be great depending on the application. Let’s just ditch the false simplicity and flatness.
Every single time I'm on desktop and I see a GUI that sucks, I know it's mobile's fault. Why this button so big? Mobile. Why spacing? Mobile. Why this list of 6 clickable items with one line of text each takes up my whole screen's vertical space? Mobile. Why no more status bars and tooltips? Because you can't hover on mobile. Why is the filter of this table below the table instead of above the table's headers? Because the thumbs won't reach the top on mobile. Why the headerbar buttons have no labels? Because they wouldn't fit in the horizontal space in mobile.
I'm really not a fan of mobile. If possible, I'd rather ignore it completely and just let mobile users rotate their screens.
