Live data from Hacker News

MDN Plus

hacks.mozilla.org

211–220 of 322 posts

Re: MDN Plus

#211

Fundamentally, maintaining MDN is costly because of the rate of instability in rapidly changing browser APIs. Those APIs change quickly and inconsistently because they’re managed by a centralized cabal of a few corporations with a combined multiple trillions of dollars in market cap. And yet, somehow it’s Mozilla, the browser vendor with the least money, that ends up saddling the cost for MDN. Why is this? In general…

I agree. I have no critique of Mozilla for charging, but it's pretty infuriating that big tech calls the shots, contributes so little, and thus puts the rest of us in a position where we have to pay for the privilege of access to documentation of APIs that they define (and churn[0]). These companies really are the pits.

[0] Of course, my other bugbear here is that this constant churn adds non-trivial quantities of non-value-adding effort to my roadmap and backlogs. Again, individuals and smaller companies pay the price for big tech's high-handedness. Not cool.

Re: MDN Plus

#212

I’m not sure I’ve ever felt like I’ve needed to personally organize parts of MDN but I might just subscribe to support the place. Who knows, maybe I’ll love the new features. Notifications could be helpful, though I’m more the “check in when I’m about to use some method to see if it’s changed” kind of engineer and less the “stay as up to date as possible” kind of engineer. ¯\_(ツ)_/¯ But hey, I’ll be supporting Mozill…

Notifications could be hugely valuable for developers who are looking to build feature-rich apps that rely on lots of new web platform features that are not yet supported on all browsers.

Depreciation alerts might help too. I wonder if MDN could build a tool to go through your HTML and JS/TS and notify you of upcoming changes that might impact you.

Re: MDN Plus

#213

Fundamentally, maintaining MDN is costly because of the rate of instability in rapidly changing browser APIs. Those APIs change quickly and inconsistently because they’re managed by a centralized cabal of a few corporations with a combined multiple trillions of dollars in market cap. And yet, somehow it’s Mozilla, the browser vendor with the least money, that ends up saddling the cost for MDN. Why is this? In general…

I agree. I have no critique of Mozilla for charging, but it's pretty infuriating that big tech calls the shots, contributes so little, and thus puts the rest of us in a position where we have to pay for the privilege of access to documentation of APIs that they define (and churn[0]). These companies really are the pits. [0] Of course, my other bugbear here is that this constant churn adds non-trivial quantities of no…

If you take a follow the money perspective to understanding this frustrating behavior, you can see plainly that it is systemic and the only behavior to expect out of the economic model these companies operate within. These are not individual bad actors

Re: MDN Plus

#214
> "In 2020 and 2021 we surveyed over 60,000 MDN users and learned that many of the respondents wanted a customized MDN experience. They wanted to organize MDN’s vast library in a way that worked for them."

in 2022, i really hate this "users told us" phrasing, because it's always misleading, and even normative at the margin. users didn't tell you anything, you inferred that from, here, a single survey (and that's more pretext than most provide). left to our own devices, users express feelings first and foremost, even if formulated reasonably. it's almost always ad hoc rationalization, because most users don't care enough to think deeply enough about your product in that moment of inquiry. you have to elicit and infer what they value, and there are plenty of quantitative (marketing) techniques these days to do so, but that takes real work and forethought.

this is one of those cargo-cult product (marketing) phrases i hear over and over, and it's naive at the very least. it's also how you get a product feature list that most people here (potential customers and customer advocates) seem to feel is lackluster and are even mocking.

with all that said, i find this offering at least closer to something i'd pay for than something like pocket or vpn. there are tons of value-added features that mozilla can offer on top of a browser and web dev that no one else would really want to tackle. they just need to do some real market research, rather than larp'ing it.

(i really should start a product blog just to catalog all these silly things.)

Re: MDN Plus

#215

Earlier quoted context omitted.

I would love to see a solution like that. Or even if we could reliably tie a corporation to pay a fixed amount if they use free software would be nice.

You won’t find a satisfactory solution to this under the economic model they operate within

Taxes are real. I even read about them in a modern economics text book.

Re: MDN Plus

#216

Earlier quoted context omitted.

(unrelated to the main topic) > The other day I wanted to learn Svelte... Any highlight(s) regarding positive/negative experiences that you had with Svelte so far? Asking because it's on my to-do list for my future frontend (bought 2 books about it, but pending to be read as I'm currently first trying to assimilate "Rust" to program the backends) and I ended up selecting Svelte as potential best candidate after havin…

> Any highlight(s) regarding positive/negative experiences that you had with Svelte so far? Sveltekit was a bit of a pain to get running, but using svelte itself has been insanely nice. I got an entire internal website up and running with a bunch of cool functionality in ~3 days. The state management with Redux alone would have taken that long if I was using React. Being able to just use regular HTML is also nice. Th…

Thank you! :)

Re: MDN Plus

#217

Fundamentally, maintaining MDN is costly because of the rate of instability in rapidly changing browser APIs. Those APIs change quickly and inconsistently because they’re managed by a centralized cabal of a few corporations with a combined multiple trillions of dollars in market cap. And yet, somehow it’s Mozilla, the browser vendor with the least money, that ends up saddling the cost for MDN. Why is this? In general…

If W3C or WHATWG try to "tax" Google, Apple, or Microsoft to participate, they will lose all significance the next day as big tech starts their own exclusive group to define web standards. They completely control all influential browsers. Whoever makes the implementations gets to choose the standards. Unlike governments, standards committees have zero enforcement power.

So put the governments in charge of the standards committees.

I would personally never advocate for that, but it’s a potential solution.

Re: MDN Plus

#218

Fundamentally, maintaining MDN is costly because of the rate of instability in rapidly changing browser APIs. Those APIs change quickly and inconsistently because they’re managed by a centralized cabal of a few corporations with a combined multiple trillions of dollars in market cap. And yet, somehow it’s Mozilla, the browser vendor with the least money, that ends up saddling the cost for MDN. Why is this? In general…

[deleted]

Re: MDN Plus

#219

Earlier quoted context omitted.

Mozilla Foundation is non profit. Mozilla corporation is for profit. Mitchell Baker owns it all and draws a salary from the corporation according to public records. Pretty sure the foundation owns the IP etc and the corp leases it, funneling money around. Statements are public.

When you say "Mitchell Baker owns it all", you aren't claiming that Mitchell owns Mozilla Corp, are you? Mozilla Corp is owned by Mozilla Foundation, as described in the Wikipedia article: https://en.wikipedia.org/wiki/Mozilla_Corporation Most Mozilla employees draw their salary from Mozilla Corp.

Who owns the foundation?

Re: MDN Plus

#220

The other day I wanted to learn Svelte. Even though the tutorials on the Svelte homepage are great, I found the MDN Svelte tutorial to be better: it explains the conceptual differences wrt other frontend frameworks well, it explains in detail how to enable Typescript and migrate your projects, and it has a dedicated section that describes different deployment options. While of - of course - all of these infos can be…

(unrelated to the main topic) > The other day I wanted to learn Svelte... Any highlight(s) regarding positive/negative experiences that you had with Svelte so far? Asking because it's on my to-do list for my future frontend (bought 2 books about it, but pending to be read as I'm currently first trying to assimilate "Rust" to program the backends) and I ended up selecting Svelte as potential best candidate after havin…

Pros: - Very easy to learn. If you know TS/JS+HTML, there are ~ a handful new syntax expressions to learn, but otherwise you're good to go. - Easy to integrate an external CSS framework such as bootstrap - Built-int TS support. Being able to use types in your frontend code is delightful. Cons: - The generated output puts the vast majority of the content in the JS files (vs having a least some skeleton or so in HTML).
Post reply on HN