I do think we need something like RSS, but RSS as it is has several immense problems that hurt its adoption. I'll list the problems I found here.
1. RSS isn't HTML. I know how to write HTML, I don't know how to write RSS. It's probably not hard, but it's one extra thing to learn.
2. You don't know what your website's RSS looks like until you use it. This is like using a screen reader. When you check your website, your articles, posts, etc. you check in the web browser. You edit it to look good in a web browser. You won't catch that something looks wrong in RSS unless you open it in a RSS client. And honestly, there are just way too way too many modes to view a single article! Desktop, mobile, tablet, RSS, screen reader, how it looks when you share it in Facebook, Twitter, how it looks on Google, on AMP. Nobody is going to check every single one of these.
3. The default RSS CMS implementation doesn't align with most publishers' interests. By default, CMS's will just put all of the content of an article as a RSS item. Most websites that make money off writing content need you to go to their website to see ads or buy things to make money. This is why social media thrives where RSS doesn't. Social media users only get the headline, and they may have long, verbose arguments about that headline, but they won't read the rest of the article unless they actually go to the website.
4. It's non-trivial to change this RSS implementation. The only reason why so many Wordpress websites expose a RSS feed despite that going against their interests is because the owner doesn't know what RSS is! If they knew, they would disable it right away! But you might be thinking, why disable it when you can just change it to look like social media? Because it's simply not that simple. Changing the HTML output of CMS's is very easy because that's a common use-case. Lots of documentations, tutorials, etc. Changing RSS or even a sitemap.xml is arcane knowledge. Personally I don't even know what is the point of having RSS feeds per article for the comments. Who uses this?
5. RSS clients have an unique, subpar experience. One thing that is immediately obvious if you check a RSS client is that it's fundamentally different from a social media feed since there are no huge, irrelevant images on every post. Imagine you see an article about something remotely related to Amazon, without a photo of Jeff Bezos under it. How can people consume content like this? You can get feeds from Youtube without Youtubers making stupid faces on the thumbnails! That's bad for click rates! In all seriousness, because of how ignored RSS is, you can end up in a situation where an article's HTML exposes metadata such as the article image, but the RSS feed has no image on it, or the article has widgets that require JS, but the RSS client can't run javascript, or the RSS feed needs CSS to make its text colored or something, but the RSS feed didn't get that, etc.
6. No discovery. Chrome could literally just show me a RSS icon in the address bar to say it's available (like Vivaldi does) but it doesn't, which means nobody knows you have a RSS unless you tell them, and most website owners won't tell their users about their RSS because they don't even know they have RSS to begin with. Most places you can search for RSS feeds are online clients, and if I'm using an online client I may as well just use social media. Why is it so hard for people to just put add some keywords/tags field in their RSS and then make a link aggregator that is like subreddits but it just pulls articles from a thousand different feeds and sorts them according to their tags automatically? That would be a win-win-win for everybody!
Honestly, I think it would make WAY more sense if instead of RSS, which has its own markup, its own URLs, etc., we just had local "feed clients" that you gave a URL to, and it just searched all <article> elements or rel=bookmark or something like that, found their respective URLs, downloaded the HTML of every article, and showed the <title>, <meta> description and image in a feed just like a search engine would, with a favicon too. We could even use the dreaded <meta keywords>. But of course HTML dropped the ball by making the <article> mean things that aren't actual articles and even things that don't have their own URLs, titles, or descriptions, so this would need its own schema/microformat, which nobody would implement because nobody uses this client yet, which is why RSS is the best we got even though it's just not as good as social media for a number of reasons.
I even use a cli rss client and i have no issue with images. They get pulled out of the article and mapped to a number on the keyboard, hit that and the direct image link opens in a firefox window behind my little article window. Works for me. Beats looking at the website. Javascript I am glad I never see it. As far as no discovery, I have discovered these feeds I follow somehow haven’t I.
That's even worse. I'm talking about putting a large image under the article's headline, the way every social media feed does it. Although I hate irrelevant images, the human brain can recognize images faster than it can read text. If articles had a relevant images, you would be able to find interesting articles just by glancing at a masonry grid on the screen.
But in order to do this, the RSS code needs to include the images in first place, and there is no guarantee it will even though the HTML side will usually have it properly marked up.
What other, more honest endeavors are you talking about?
It's very easy to attack others when you don't need to defend yourself. I want to see you say these things when you have an alternative with its own share of problems.
I've observed another meta as well: IDEs/language servers.
I was writing a Wordpress plugin and by default in PHP all function definitions are global, e.g. is_single that WP defines is global. Naturally to avoid conflicts you would use a namespace, but since most of the examples I saw used prefixed function names, I decided to try that as well.
In my opinion, coding just feels much clearer when you prefix all your names, like my_library_my_func. When I see my_library_, I just immediately know that is my code. If you use different prefixes for different modules, you can tell from a glance which modules a piece of code interacts with. In C++, you can tell a random word is a field by the simple fact everyone prefixes them with m_. I've seen people using prefixes for pointers as well.
This is the same concept you have when designing an UI. Everyone agrees a problem with hamburger menus is that you don't know what's inside the burger until you click on it. If you want people to be aware something exists, you need to make it appear on screen, explicitly.
Instead, languages have evolved toward the very opposite. We ran away from self-documentating variable names and prefixes, and toward namespaces, "const" and other keywords, and "OOP" that feels less object-orientated and more press-the-dot-key-to-get-a-list-of-methods orientated. We depend on docstrings that show in the IDE, and then on auto-generated documentation from those docstrings. Typescript is probably the worst case of this, because it gives you a lot of tools to make the dot work the way you want, you'll spend way too much tinkering with the dot instead of just writing code that actually runs.
Thanks to this, when you look at code, you have to wait until your language server figures out what you're looking at for you. If the IDE doesn't work, it's effectively impossible to code anything in many cases. But the variable names are shorter so people think it's cleaner and better, like removing features from an UI to make it cleaner.
A language where every definition is global is the worst starting point imaginable. Of course, solutions to that will remain severely lacking. Prefixed variables as you propose were abandoned for good reason.
Perhaps give Rust or Python, maybe Go a spin, and see how they do namespaces, imports and such. I find that mostly sane and readable, as they retain the full chain of custody (you can always trace where a symbol comes from by its qualification or import statement, unlike in less sane ecosystems such as C/C++/C#/Java, and apparently the insane version PHP uses).
Modern C# is a lovely language overall but I think OP talked about the module system where the more explicit approach of Python is arguably better.
When dealing with C#, if you’re browsing code un anything less than a IDE it can be really hard to find where a symbol comes from. And that is if the author was nice enough to use one folder per namespace, otherwise it becomes a nightmare.
In case of external references, most of the time, you do not need to browse the source files - that's something you reach for if inline documentation and type system are insufficient. Arguably much more of an issue in dynamically typed languages, yes.
Although even source browsing is now easy - you just press F12, and packages come with sourcelink integrated automatically (previously you had to rely on IDE to resolve symbols or decompile it from IL (readable but not perfect, Rider did and still does it really well)).
Navigating the solution itself does not differ significantly from Rust and its crate system. People usually structure the code by projects and folders, sometimes aggregating multiple types in a file (because you don't need a separate file per a couple of 4 line class declarations) sometimes not but I generally find the structure way more browsable than e.g. what a typical TypeScript project looks like. The regular symbol navigation rules apply - F12, Shift+F12 and friends.
In Rust, Python and Go you can trace every symbol back to its source by just reading source code. `cat file` would suffice.
In C#, that’s impossible by design, as you say. C# imports work like wildcard imports in Rust and Python, which are wildly frowned upon for very good reason (except for specific cases like preludes in Rust).
It won't. If Youtube had no moderation, it would have no ad revenue. This would effectively kill every single website where users can publish content without having to go through a publishing contract first.
Youtube, Medium, Newsgrounds, every single comments section on news articles, all web forums, Discord, reviews on Amazon, Steam. I'm not even sure websites like buy me a coffee and patreon would be able to survive, because if they can't moderate their posts, that doesn't mean mastercard can't ban them, as mastercard isn't subject to publishing laws.
Mastercard et al are able to act as censors of the internet because websites have discretionary moderation policies. If, when mastercard demanded policy changes, websites could only respond with "sorry, it's out of our hands", then mastercard would give it up pretty quick. If they didn't, then bitcoin would become temporarily quite popular until they did. People want to be able to pay for things online, and credit cards are able to boss websites around only insofar as they don't push the envelope too far.
That's not going to be how things are likely to work. The financial industry censors disreputable sites because, effectively, disreputable sites are too expensive to support (e.g., high chargeback rates). The big social media sites today aren't going to "gee, golly, we have to completely abandon moderation to deal with liability now"; no, they're going to ramp up their moderation hard, because reputational risk is still a thing (also, they still have liabilities in countries that aren't the US that they are going to be very concerned about!).
And when you have sites like Youtube that retain a strict moderation policy, there is going to be absolutely 0 incentive for them to cave to whatever new niche sites crop up that try to play the "we can't enact moderation" card, exactly as happens today.
If youtube (and every similar website) was forced to abandon content moderation (or cease being "you"tube), that wouldn't substantially increase their chargeback rate.
> ramp up their moderation hard
Not good enough. Every claim about a person in every video posted to youtube would need to be fact checked prior to being visible on youtube. You are underestimating the degree to which this kills youtube qua youtube. This is subtantially more true for facebook, or for comment sections.
>still have liabilities in countries that aren't the US
Already most sites that are required to censor content for a certain locale only block it for IPs from that locale. I doubt this would change.
> Every claim about a person in every video posted to youtube would need to be fact checked prior to being visible on youtube.
No it doesn't. Defamation requires some form of mens rea of the statement being made (negligence or actual malice depending on who it's about), so liability for defamation in a no-§230 world largely means "will take it down after someone complains" as there's a pretty solid defense that not verifying the statements before uploading doesn't constitute even negligence, much less actual malice.
The liability rules in a no-§230 world aren't entirely clear since we're basing everything on just two court cases that existed pre-§230, but the social media companies are going to be extremely willing to throw down millions of dollars in legal fees to persuade judges to evolve liability rules that make their moderation policies feasible.
And this comes back to the main point again: no moderation just doesn't scale, not even in channels of merely a hundred people, let alone hundreds of millions. It is naïve to think that companies are going to suddenly decide that "no moderation" is less risk than "tailor both our moderation policies and the law to find some middle ground that is actually feasible."
They think if you remove 230 they won't act as an editor, but only as a publisher, which means ZERO rules for content published except what is illegal by law.
Anyone who has moderated a forum in their lives know how exceedingly stupid this idea is.
If you don't need an account or an api key to access it, then there's no contract signed, and so they can't restrict your usage contractually. An API with no requirement for an API key is functionally identical here. On the other hand, scraping a website that only exposes content to logged in users is the same as using an api behind a key. The relevant part is whether you need to sign a contract to access the content.
I think that ship sailed when websites started having to ask users consent for cookies. Now it's no longer "accessing a website" it's "interacting with a service." If they have to ask for consent to set a cookie, you have to abide by their ToS to connect to their servers.
I highly doubt that is legally the case. In situations when I have been in conversations with lawyers about this sort of thing they have been universally of the opinion that to be bound to some terms of service the user has to take an affirmative action to accept those terms. The action can’t just be expressing your cookie preference, and in fact in some jurisdictions (Europe, California? I think) the cookie regulations that gave rise to those annoying consent dialogs specifically say you can’t give a user a different quality of service if they refuse the cookies, so that would seem to undermine your argument somewhat.
DDoS is arbitrary with any definition. What’s the difference between a weak server that can’t handle an influx of load vs an “attack”? The result is the same. It all depends on intent and coordination, which is better defined by lawyers than engineers.
To some extent, you have to expect that anything with an open port 80 on the public internet is accessed by strangers. First because it’s the technical reality, but it’s also part of the principles of the web in some deeper philosophical sense.
Now: I know this app existed.
Having no polish can't be worse than having no app.