How are you handling analytics? Will distribution be through a customer's Spotify/Apple account (so analytics are visible), or will you be building a portal to combine the two sources (plus server-side download logs, maybe?) of analytics for customers?
The beginning will be trough a spotify account for the customer. Every customer gets a [username]@podcasts.castyt.com email address. This is used for all registrations and can also be used for gathering the spotify analytics.
iTunes and all other podcasts players load the files directly from the castyt server, without caching as of why the analytics will be based on the file access. (Anonymized IP)
Step two is a complete analytics dashboard inside castyt combining all sources
I really don't understand the glorification of no-js websites on HN. Like, I'd get it if it was Flash or something ('cause that definitely has some real accessibility issues, and required a plugin to be installed), but the web platform is HTML, CSS and JS. Why artificially limit yourself to just two? It seems to have become a matter of pride to say "works without JS", for absolutely no practical reason (it's not like removing JS is some silver bullet for accessibility, no-js sites can and do still absolutely have problems with accessibility)
JS is usually what kills performance on lower end devices. If websites were only html and css, my smartphone from 2015 would still be a functional device. I have yet to have a page crash due to too poorly written html and css.
It depends what you're doing with the JavaScript. This is like saying "C kills performance" because you found one slow C program. JavaScript can actually improve performance in quite a few conditions (even on lower end devices) by preventing full page reloads and such, which adds more overhead in the network, HTML parsing, etc.
If we're talking about saving bandwidth, JS can be useful, although JS bundles are usually heavier than their HTML and CSS counterparts.
I have yet to see an example where rewriting the DOM would end up being lighter on devices with lower-end CPUs and RAM than doing a full page refresh. Browsers already cache static assets, generally a page refresh only takes a second or two (on reasonable connections)
A common example is when you have a page with information and you want to load some additional data or details to display (possibly just a single line). Often times, a a simple AJAX request is faster, and it's also often better UX, IMHO. There are loads of examples of this, but people don't tend to notice when it works well and only remember the examples where it doesn't (like, say, the new Reddit UI).
The application I work on initially used to work completely without JS, but I let that go and now you need JS. It made everything faster, more performant (even on my shitty phone), and the code easier to work with. And it's just 770 lines of JS (+ jQuery, because I think it's just more convenient than dealing with the DOM API).
I have nothing against Javascript when it improves the overall result. However, when I come across a site which consists of text articles interspersed with some static images, and the images do not show with JS disabled, or in extreme cases, the entire page remains empty because it needs JS to even display text, that just screams wrong.
Web has been able to display well-formatted text and images for decades without Javascript just fine. In fact, that has been its original primary purpose, to display text with hyperlinks and some images. Why bastardize it just because you want your images to load with a cool effect or something equally silly (that won't work well for half of the visitors anyway) ?
In a lot of cases it's worth considering whether orchestration is necessary at all — pure docker can take you quite far, with just a couple shell scripts called from the last stage of your CI (or manually)
It seems like your specific use case could be solved (as you mentioned) by passing down a `className` prop, exactly like React. It's described as a workaround in the RFC because the approach there relies on internal class names (and couples the internal component API to the parent), whereas you'd be passing in the specific class you'd be using. Something like this should work, without going too much against the grain of the framework:
// Parent.svelte
<script>
import Child from "./Child.svelte"
</script>
<style>
.container :global(.child) {
color: red // your styles here
}
</style>
<div class="container">
<Child className="child" />
</div>
// Child.svelte
<script>
export let className
</script>
<h1 class={className}>I am styled by my parent</h1>
This seems in fairly bad faith. As best I can tell, it suggests that the argument that billionaires exploit people is unfounded, because they delight _users_? I mean, sure, but that says _nothing_ about exploitation.
A company that exploits its users won't generally do well, but that doesn't mean that it doesn't exploit its workers, which is generally what politicians mean here (see Amazon, for instance. Or, since Facebook was brought up in the article, their content moderation team)
