[HN Gopher] MDN Playground
___________________________________________________________________
MDN Playground
Author : weinzierl
Score : 219 points
Date : 2023-07-20 08:39 UTC (14 hours ago)
(HTM) web link (developer.mozilla.org)
(TXT) w3m dump (developer.mozilla.org)
| cassepipe wrote:
| My problems with all those playgrounds is that I don't know where
| shortcuts are and when there are shortcuts, it's full of Ctrl
| combination that may clash with the browser...
|
| Can I has a vim mode please ? I am not returning back to using
| arrows to move around text
| 8n4vidtmkvmk wrote:
| "install" the web page. That opens up more keyboard shortcuts.
| spankalee wrote:
| If you ever want to add a client-side-only playground to your own
| site, have a look at the Playground Elements project:
| https://github.com/google/playground-elements
|
| It's a set of custom elements and a service worker that populate
| an iframe with the contents of the code editor with no server,
| but in a way that looks like real network requests to the iframe.
|
| This means you get a root HTML page and all the right loading
| behavior and ordering as a real hosted web page. Inspect the
| iframe with devtools and you see exactly what you wrote, nothing
| added by the playground.
|
| The elements also support Node-style import specifier resolution,
| pulling npm dependencies automatically from unpkg.com,
| TypeScript, and JSX.
|
| And the elements are very configurable. You have drop in a
| tabbed-editor and preview combo element, or you can separate the
| preview and editors for each file - which lets you write prose
| around each.
| catsarebetter wrote:
| The AI Help feature looks super interesting, any plans to
| integrate it into the playground?
| jai_ wrote:
| I sincerly hope that they remove this feature and apologise for
| its integration in the first place.
|
| I don't think a reference website should include any sort of
| feature that can hallucinate incorrect documentation for you on
| demand.
|
| It's bad enough that they have to include a disclaimer[1] on
| their upsell page, which states that the "AI Help" may
| occassionally return incorrect results.
|
| [1]: https://developer.mozilla.org/en-US/plus/ai-help
| hagreet wrote:
| Please no. The site is an important resource for people
| learning JS and other web technologies and AI is great at
| explaining code snippets which would otherwise be follow-up
| look-ups and at explaining what the often very dense MDN
| content means. And AI is actually really good at generating
| code as well, you just have to review it like it was written
| by a junior dev.
|
| I think most of the hate for current AI tools comes from the
| fact that people expect the computer from Star Trek which
| always provides perfect answers.
|
| Edit: So yes, it needs to be made super obvious to users that
| it might give you wrong answers.
| sensanaty wrote:
| Except it gets mostly everything wrong, even very simple
| things that are on the page itself.
|
| https://github.com/mdn/yari/issues/9208
| jai_ wrote:
| I'm really not sure how you can argue that "AI is great at
| explaining code snippets" while also acknowledging that it
| will just give you flat out wrong answers some times.
|
| Either it's good at explaining and is right, or is bad at
| explaining and is wrong.
|
| Applying the logic of it being "right most of the time"
| seems really bad for a tool applied to a reference
| documentation website.
| mkhizar53 wrote:
| shows why simple works
| pdmccormick wrote:
| Last week I signed up for an annual subscription to MDN. I didn't
| realize it at the time, but paying subscribers get the option to
| enable offline mode (it currently downloads about 630 MiB of
| content). I generally have fast connections wherever I'm working,
| but the difference between "fast" and "instant" when loading new
| pages is really making the experience feel special for me. I
| would heartily suggest you support MDN and try it out!
| capableweb wrote:
| Not sure if it's a bug or not, but the JavaScript editor seems to
| only try to autocomplete reserved keywords and not much more,
| unlike the HTML and CSS editor. I'd expect it to show me at least
| functions available at window., document. and console. , as an
| example.
| toinewx wrote:
| so basically codepen
| [deleted]
| Pixie_Dust wrote:
| [flagged]
| jerrygoyal wrote:
| I liked that it is lightweight than codesandbox, stackblitz
| etc.Also, surprised that it has intellisense but it doesn't work
| for `console.log`.
| qsort wrote:
| It's something more like jsfiddle than a full-blown dev
| environment like codesandbox or stackblitz.
| msoad wrote:
| They have to solve the problems JSBin and like solved years ago
| all over again. Starting with infinite loops ;)
| ogaistan wrote:
| Funny that you mentioned this as I added some heuristics to my
| playground [1] yesterday for this use case. It relies on Babel
| [2] which looks for `for`, `while` and `do-while` loops and
| injects a counter that throws an 'infinite loop detected' error
| to prevent the browser freezing. You can opt out if you know
| what you are doing. It's not perfect, but it covers this base
| cases.
|
| [1] https://www.jsplayground.dev [2] https://babeljs.io
| KRAKRISMOTT wrote:
| Any chance emmet and autocompletion can be added for the editor?
| mg wrote:
| For some reason, I never liked that all the code playgrounds have
| separate windows for HTML, CSS and Javascript. It makes it hard
| to grok what is going on. Does the CSS and JS get injected into
| the HTML? Is it loaded via injected <script> and <link> tags?
|
| I'm also never sure what magic gets wrapped around the html I
| type. Does this thing add a DOCTYPE? A header? Or can I define my
| own header? Etc.
|
| So I made this one, where you edit just a raw html page and see
| the output right away:
|
| https://no-gravity.github.io/html_editor/
|
| The code is here:
|
| https://github.com/no-gravity/html_editor
|
| One way I often use it is that I copy the whole source (via view
| source) of a page, paste it into the html_editor, add a <base
| href="url_of_the_page"> to it and then I can try realtime changes
| with all the external CSS and JS being loaded just as it is on
| the original page.
| lelanthran wrote:
| > or some reason, I never liked that all the code playgrounds
| have separate windows for HTML, CSS and Javascript. It makes it
| hard to grok what is going on. Does the CSS and JS get injected
| into the HTML? Is it loaded via injected <script> and <link>
| tags?
|
| Tbh I also never liked it, for all those reasons you listed.
|
| Ideally it would be a left panel with a treeview list of files
| with the selected file displayed on the right panel in an
| editable element.
|
| Output should be a different window which updates on every
| change.
| tomcam wrote:
| Yes cubed! Thank you.
| viraptor wrote:
| > Does the CSS and JS get injected into the HTML? Is it loaded
| via injected <script> and <link> tags?
|
| Does it matter? (Serious question) Not for a full website where
| it matters for duplication / caching / performance, but in this
| context - for the playground.
| recursive wrote:
| Sometimes yes, sometimes no.
| 8n4vidtmkvmk wrote:
| Yes, the placement of the script tag very much matters, but
| it's most likely after your html or deferred to run after
| your html, in which case... Not really.
|
| There is one little quirky js thing you can do to get the
| script element from inside the script but I doubt many people
| are doing that.
| Eduard wrote:
| > There is one little quirky js thing you can do to get the
| script element from inside the script.
|
| Now you *have* to elaborate. And what's the problem it
| solves?
| chrismorgan wrote:
| I do stuff like this regularly: <div>...</d
| iv><script>document.currentScript.previousSibling....</scri
| pt>
|
| Provided you care even vaguely about code size (and are
| ending up with handfuls of kilobytes at most, not multiple
| megabytes), inlining everything is _excellent_ for
| performance (seriously, unreasonably effective, _way_ more
| than most expect), and if it's stuff that must be done
| before the document is fully interactive, then doing it
| immediately like this rather than messing around with
| DOMContentLoaded event handlers and querying and such is
| likewise _excellent_ for performance.
| cetinsert wrote:
| https://RTCode.io is our single-pane, reload-free, HTML/CSS/JS
| playground!
|
| Video: https://rt.ht/yt (multi-device, live sync without
| reloads)
|
| Home: https://elefunc.com/#rtcode_io
|
| Playground: https://rtcode.io
|
| Network: https://rtedge.net
|
| ---
|
| To import from CodePen:
|
| * https://codepen.io/jkantner/pen/NWEgzoK (original)
|
| * https://rt.ht/codepen.io/jkantner/pen/NWEgzoK (import)
|
| * https://rtcode.io/jkantner/pen/NWEgzoK (import)
| AndroidKitKat wrote:
| This is very nice, and I can see myself using this in the
| future. However, I have one slight piece of feedback; is
| there any chance you can make the delay on the menus flying
| out and tooltips just appearing all over the place when I
| move my cursor just a little bit longer? I felt like I was
| getting bombarded with information by just wanting to move my
| cursor to the other pane.
|
| Besides that, I like it. Thanks for the links.
| cetinsert wrote:
| We will increase the delay. Thank you for the feedback! You
| can reach us anytime at support@rtcode.io
| xyby wrote:
| Does not work at all for me.
|
| Is this a commercial product?
| cetinsert wrote:
| What is it that does not work? You can also email us at
| support@rtcode.io
|
| * https://new.rt.ht (try starting fresh here)
|
| If you cannot save your code, just save the URL which
| encodes the complete state down to the selected text
| ranges.
|
| Saving/deployed to 275+ Cloudflare locations may not be
| available globally yet.
|
| It is will be a free playground with commercial features,
| such as edge-deployed workers which can be developed in-
| editor:
|
| * https://sw.rt.ht/? (in-editor)
|
| * https://sw.rt.ht (edge-deployed)
| gpmcadam wrote:
| One of the strangest things to infect the web development
| community was that separation of concerns somehow meant
| separation of HTML/JS/CSS, which to me always felt like the
| opposite since very often the HTML, the JS and the CSS were all
| very much concerned with one another e.g. a React component
| where the rendered HTML, the logic behind it and how it's
| styled make sense to live next to one another.
|
| I think it's for this reason you often see those languages
| split out in code playgrounds. And I also think it's a big part
| of the initial pushback against css-in-JS libraries such as
| styled-components or Emotion.
| bityard wrote:
| There is no one rule that fits all projects, this is what
| being an "engineer" is all about. If there were hard and fast
| rules for building applications, all of us here would either
| be out of a job, or doing the software equivalent of working
| on an assembly line.
|
| However, my own personal guidelines are::
|
| * A small project lives all in one file.
|
| * A medium project is organized by what the files are
| (markup, images, etc).
|
| * A large project is organized by its major components, and
| how those components are themselves organized depends on
| _their_ size and what they do.
|
| * Never be afraid to reorganize a project if (and only if) it
| makes sense.
| CharlesW wrote:
| > _...very often the HTML, the JS and the CSS were all very
| much concerned with one another e.g. a React component where
| the rendered HTML, the logic behind it and how it 's styled
| make sense to live next to one another._
|
| This is why I absolutely _love_ Vue single-file components.
| AFAIK, there's no elegant substitute for these in React.
|
| https://vuejs.org/guide/scaling-up/sfc.html
| agency wrote:
| Not trying to start a flame war but what can you do with
| these that can't be accomplished with React and e.g.
| https://styled-components.com ?
| toyg wrote:
| It makes more sense if you think that an HTML is a static
| document, which then gets decorated by CSS, and lightly
| animated by JS.
|
| That is what the web was built as. We were supposed to
| _browse_ documents like we browsed magazines. Your React
| monstrosities were hacked on top of that model, turning the
| browser into an application runtime - which it wasn 't meant
| to be.
| doctor_eval wrote:
| That's a misreading of history. Here's the announcement for
| JavaScript, which was posted here just yesterday[0]:
|
| It says,
|
| > MOUNTAIN VIEW, Calif. (December 4, 1995) -- Netscape
| Communications Corporation (NASDAQ: NSCP) and Sun
| Microsystems, Inc. (NASDAQ:SUNW), today announced
| JavaScript, an open, cross-platform object scripting
| language for the _creation and customization of
| applications_ on enterprise networks and the Internet.
|
| (Emphasis mine)
|
| JavaScript was _always_ meant for building applications.
|
| [0] https://news.ycombinator.com/item?id=36782761
| moritzwarhier wrote:
| Even assuming JS that was originally meant for hover
| effects (or "rollover") and other "light animation",
| complex web applications predate React by a lot.
|
| Think Outlook Web, Google Maps, and all the smaller apps
| built with frameworks of their time such as Dojo, YUI etc
|
| There also are monstrosities with the server at the
| center...
|
| applications with hundreds of hidden form fields per
| page, required server sessions for anonymous users, DSLs
| in half-baked server-side templating languages, server
| code generating and injecting opaque JS to sync state
| with the client, the list goes on.
|
| And these things all have ups and downs themselves I
| guess, just like React has.
|
| In fact animation is one of my least favorite uses of JS,
| the more I can do in CSS, the better.
|
| As a user sometimes I enjoy complex animations but only
| when it serves a purpose.
| toyg wrote:
| Those applications were meant to run _on the server_ ,
| more precisely on the Netscape proprietary appserver. On
| the browser they were meant to do popups and basic form
| validation at best. There was not even a network
| communication mechanism!
| doctor_eval wrote:
| This is not what was intended. Just read the 1995
| announcement - straight from the horse's mouth. It was
| clear that Netscape had big plans for this. JS had its
| limitations, sure, but it could talk to Java on the
| client - which certainly _did_ have network access. And
| famously, Microsoft felt so threatened by this new
| "platform" that they feared it would make Windows
| redundant. The late 90s was a wild ride.
|
| > JavaScript is an easy-to-use object scripting language
| designed for creating live online applications that link
| together objects and resources on both clients and
| servers. While Java is used by programmers to create new
| objects and applets, JavaScript is designed for use by
| HTML page authors and enterprise application developers
| to dynamically script the behavior of objects running on
| either the client or the server. JavaScript is analogous
| to Visual Basic in that it can be used by people with
| little or no programming experience to quickly construct
| complex applications.
| toyg wrote:
| You just have to read that to see how JS was just meant
| as a bit of glue between JDK and html pages. Java would
| do the heavy lifting everywhere.
| yCombLinks wrote:
| Frankly it doesn't matter what it was meant to be, and it
| doesn't help at all thinking about it as a way completely
| separate from reality.
| z3t4 wrote:
| Web/JS did what Java tried to do, a runtime that works on
| all platforms. The problem is that its too heavy weight.
| But platform lockdown will prevent any competition.
| lelanthran wrote:
| I think the real problem is that CSS mixes in two many
| different concerns.
|
| If I want to create a reusable component I need to control
| the layout tightly, and use media queries for display size.
|
| The user of the component needs to control the colour and
| cosmetic stuff, while also using media queries, but for
| dark/light mode.
|
| All four use cases use the same bloody input - CSS! Which
| means all of the different parties are stepping on each
| others toes because they may accidentally set a property that
| needs to be set by a different party.
|
| It's not designed for separation of concerns.
| Eduard wrote:
| > All four use cases use the same bloody input - CSS!
|
| All of the four mentioned use cases are stylistic. So it is
| desirable to accomplish them in a domain-specific styling
| language.
|
| Used correctly, conflicting regressions are greatly
| minified.
|
| It's just the problem with CSS that the vast number of
| developers don't know about its fundamentals, such as "CSS
| Specifity"
|
| https://developer.mozilla.org/en-
| US/docs/Web/CSS/Specificity
|
| This collective lack of knowledge leads to the kind of
| "monkey patching until it works for me (and breaks for
| you)" many lament about.
|
| Feel free to give an concrete minimum viable example
| (including code) where you are struggling with CSS, and I
| will try to give suggestions.
| sintaxi wrote:
| Agreed. Great job.
| anon35 wrote:
| Great to see. More generally: I feel like playgrounds are grossly
| underused in our industry. It's possible the issue is in the name
| -- it immediately connotes that whatever you're doing isn't real
| work, it's just a place to, well, "play".
|
| But really these kind of playgrounds are at least a cousin, if
| not a direct descendant, of the immediate feedback principle that
| underlies everything from a REPL to the kind of systems
| (Symbolics, etc) that allow you to edit running code. Their
| potential is beautifully illustrated in Brett Victor's famous
| 'Inventing on Principle' talk:
| https://www.youtube.com/watch?v=PUv66718DII
|
| Three areas that I'd love to see playgrounds mature beyond
| teaching beginners CSS:
|
| 1) Integrated directly into developer documentation. You can see
| some of that in systems that are documenting services -- for
| example, the Google Sheets API documentation has a 'Try this
| Method' box that lets you post a request to the service on the
| same page that describes it, but what I really want is something
| like that when I'm reading the man page of a destructive disk
| command, or a complex database query, or a low-level C graphics
| library. That'll require a playground wired to something as big
| as a VM, maybe.
|
| 2) Integrated into textbooks: for the last couple years the
| astonishing posts from Bartosz Ciechanowski
| ([Sound](https://ciechanow.ski/sound/),
| [Bicyle](https://ciechanow.ski/bicycle/)) have demonstrated just
| how much better a textbook could be if you could interactively
| play with the concepts you're reading about. Unlike dev docs, the
| thing you're interacting with doesn't even have to be "real".
|
| 3) Most ambitiously: integrated into the input form of bug/issue
| tracking tools. This is the opposite of play: it means a running
| system would need to be in cahoots with a playground, so that
| mature apps could let you record and playback what you saw as a
| user, allow you to edit irrelevant parts of input and output out
| and submit a complete here-look-see-it-is-busted asset for
| analysis. A Stackoverflow of the future would be orders of
| magnitude more interesting if each question was posed as a broken
| playground.
| chrisweekly wrote:
| Great comment.
|
| Related thoughts: "design systems" / UI component libraries
| often have interactive documentation sites (e.g. built with
| Storybook), showcasing variants and providing "knobs" /
| controls to edit props and see the results in realtime, so lib
| consumers can see a component working (in isolation) and
| generate a code fragment copy/pasteable into their own
| downstream app.
|
| Also, extending your item (3), project maintainers often ask
| people reporting bugs to provide an MRE (Minimum Reproducable
| Example) in a standalone repo. I've noticed a few such cases
| where the maintainers make this much easier by sharing a link
| to a basic preconfigured codesandbox or stackblitz for exactly
| this MRE purpose. I think this idea will catch on and become
| much more common.
| evandale wrote:
| I work at ${bigCorp} and am not allowed to use playgrounds :(
|
| Additionally my company won't run their own playground because
| they can't figure out how to store and audit code people put
| into it.
| recursive wrote:
| You could make your own out of a static file. You could even
| give it a "boss key" to make it show some very corporate
| looking spreadsheets or something.
| Etheryte wrote:
| Small bug report: 1) Clear the site data so you don't have a
| saved playground preloaded. 2) Focus the Javascript text area and
| type a singular "f", nothing more, nothing less, no other
| interactions. 3) The playground compiles, the cursor position in
| the Javascript text area is reset incorrectly.
| fiji-flo wrote:
| Great catch, should be fixed with our nightly (UTC) deployment.
| mintaka5 wrote:
| just for the record MDN's site, hands down, has the best
| documentation ever made by any agent of the programming industry
| krono wrote:
| The site is an absolute godsend, but it's also quite sad that
| the various standards specifications MDN covers have such
| terrible documentation websites of their own, that something
| like what MDN offers is even needed at all!
|
| Just look at the official HTML and JavaSc.. nay, ECMAScript
| specification docs[0][1]. You'd sooner end up with a headache
| than a functional website if you had no other choice but to use
| those ;)
|
| [0]: https://html.spec.whatwg.org/
|
| [1]: https://262.ecma-international.org/14.0/
| recursive wrote:
| In some (rare) cases, I find that MDN doesn't have enough
| detail. Official specs aren't as easy, but I can usually
| track down any specific behavior detail in 10 or 15 minutes.
| For the degree of precision provided, I really think this is
| not bad at all.
| chrismorgan wrote:
| The HTML Standard is _excellent_. It's long and verbose
| because of the mountains of accumulated cruft it covers, so
| that it takes a little getting used to if you're not familiar
| with the style, but it's a _magnificent_ document for finding
| specific answers in. I refer to it regularly, by choice, as a
| web developer and not a browser maker. There are large chunks
| of it that are really valuable reading for normal web
| developers. I still thoroughly appreciate MDN, but for HTML I
| could do without it without much trouble, the HTML Standard
| is good enough, _even though_ it's targeted primarily at
| implementers.
|
| CSS specs are likewise very readable and extremely useful
| reference, though they're less precise than significant parts
| of the HTML Standard. But if you have questions about how
| certain things fit together, or corner cases in certain
| properties, MDN is normally useless while the relevant specs
| are regularly invaluable. I highly recommend being familiar
| with reading these specs if you're doing even mildly
| unconventional things.
|
| The ECMAScript Language Specification: it's not like either
| of the other two; it's not a document that describes how
| things are supposed to act or how to use things, but is _full
| code_ for implementing an ECMAScript engine--just expressed
| in natural language rather than a more accustomed programming
| language. I've referred to it a number of times when I've had
| nuanced questions about _exactly_ what the engine does in
| such-and-such a case (the sort that the vast majority of web
| developers will never need or want to ask), and it's been
| useful in such cases once it finally loaded, but it's very
| firmly designed for implementers, not users. Covering any of
| the sort of stuff that MDN covers in documentation was never
| anywhere near the intended scope of the ECMAScript Language
| Specification, nor should it have been.
|
| The specs and MDN serve quite different purposes, and
| something that combined both functions would be _poor_ at
| both functions. Bemoan not the necessity of either: rejoice
| rather that you _have_ both!
| bazoom42 wrote:
| Those specs need to be extremely detailed to ensure
| interoperability. Earlier versions of the HTML specs were
| much more readable, but unfortunately lead to
| interoparability issues.
| krono wrote:
| With full appreciation of all the complexities and
| intricacies involved here, the state of these official
| documentation resources as they exist today isn't great.
|
| Additionally, most initiatives aimed at improving the
| situation have only resulted in yet more overhead in the
| form of additional committees with each their own agendas
| and procedures, or the creation of another new deeply
| interconnected but otherwise completely separate sibling
| standard[0][1][3][4], fragmenting things even further.
|
| I used to be quite heavily involved with some of the more
| meritful of those initiatives, but at some point realised
| that despite all the time and effort I was putting in,
| nothing really meaningful/impactful had been achieved or
| was even anywhere in sight, and it was also becoming too
| costly on a personal level. Guess that's my justification
| for having the right to post this rant :)
|
| [0] https://infra.spec.whatwg.org/
|
| [1] https://webidl.spec.whatwg.org/
|
| [2] https://w3c.github.io/html-aam/
|
| [4] https://w3c.github.io/html-aria/
| bsmth wrote:
| Someone put it like this recently: the audience for specs
| is browser vendors, and the audience for MDN is web
| developers; ideally, you shouldn't have to go to the specs
| if MDN describes the features well enough to get your
| application running or your problem solved. MDN docs
| consider the practical aspect of how application developers
| will use features or why they should care, so there is a
| need to keep the content accessible in as many ways as
| possible.
| bob1029 wrote:
| The quality of MDN gave me enough confidence to move away from
| frameworks and take matters into my own hands.
| Xenoamorphous wrote:
| Yet for some reason w3schools ranks higher in Google for many
| queries.
| lucideer wrote:
| There's 2 pretty reasonable reasons for this:
|
| 1. MDN's quality is higher, and it's more comprehensive when
| it comes to _new browser specifications_ , but it's much less
| comprehensive in general technology/programming topics (e.g.
| W3Schools covers PHP which many working with e.g. Wordpress
| will dabble in alongside their HTML/CSS/JS).
|
| 2. Tenure. MDN's is much much more recent - W3Schools has
| been around forever.
|
| W3Schools is a somewhat dodgy website with questionable
| quality, but it's hard to argue they've had a net-negative
| impact on educating programmers. I certainly learned a large
| chunk of my knowledge from W3Schools in the days before MDN
| docs existed in their current form.
| Phemist wrote:
| The exact reason why you need some control over your search
| engine results.
|
| For me, I have blackholed w3schools and boosted MDN in my
| search engine of choice. It is quite nice to always get the
| MDN page on a web-dev related query as the top result.
|
| Even searching for "w3schools" directly results in the
| wikipedia as the top result (which is.. fair enough).
|
| The same search on DDG results is a page full of w3schools &
| subdomains.
| endemic wrote:
| Can also use a DDG bang: https://duckduckgo.com/bangs?q=mdn
| Phemist wrote:
| Not the same, as I would then _only_ search MDN.
|
| MDN does not know anything about the battle of waterloo:
|
| https://developer.mozilla.org/en-
| US/search?q=battle+of+water...
|
| And Wikipedia does not have any real API documentation of
| `requestAnimationFrame`
|
| https://en.wikipedia.org/wiki/Special:Search?go=Go&search
| =re...
|
| I want both of these to return sensible results for the
| bang-less search. This is the easiest for me and as a
| user of the search engine product, should also be what
| the search engine delivers me.
| chrismorgan wrote:
| Using !mdn takes you to a mediocre-at-best MDN search
| page, not a specific page. My experience is that you'll
| get better results from just adding the "mdn" keyword to
| the query and jumping to the first result--that is,
| instead of, say, `mix-blend-mode !mdn` (which takes you
| to https://developer.mozilla.org/en-US/search?q=mix-
| blend-mode), `mix-blend-mode mdn !` (which takes you to
| https://developer.mozilla.org/en-US/docs/Web/CSS/mix-
| blend-m... the ! to skip the results page and go to the
| first match can be at the start or end of the entire
| query). This technique doesn't _guarantee_ you'll end up
| on MDN, but for realistic queries you're almost certain
| to.
| vadansky wrote:
| I was telling a junior to avoid w3schools and use MDN, but
| I couldn't really give him a reason besides "everyone seems
| to hate it". What's the rationale for all the shade thrown
| at w3schools?
| chucksmash wrote:
| https://www.w3fools.com/:
|
| > When W3Fools was launched in 2011, the state of
| documentation for developers was poor. This site
| documented many content errors and issues with the
| W3Schools website. The Mozilla Developer Network was
| around but it did not have much support at the time.
|
| > Today, W3Schools has largely resolved these issues and
| addressed the majority of the undersigned developers'
| concerns. For many beginners, W3Schools has structured
| tutorials and playgrounds that offer a decent learning
| experience. Do keep in mind: a more complete education
| will certainly include MDN and other reputable resources.
|
| And the archived version where you can get a flavor of
| the specific content complaints: https://web.archive.org/
| web/20110412103745/http://w3fools.co...
| Phemist wrote:
| w3schools is a for-profit company that survives on its
| schooling business. Its incentives are mis-aligned with
| mine: When I search for information on something web-dev
| related, I want it to be short & to the point. For
| w3schools, to maximize paid lesson uptake, it needs to
| only superficially explain what I want to know, enough to
| leave me confused and willing to pay for lessons.
|
| That is even assuming w3schools has accurate information,
| which historically they did not, and there is no reason
| why they will not lapse in this regard in the future.
|
| MDN has better aligned incentives on other hand, if I can
| find the information I need quickly, then I can developer
| faster and higher quality websites, which in turn in the
| aggregate will benefit the participants in MDN who are
| incentivized to increase their respective browser
| penetration (etc., I don't want to get into a whole
| discussion here).
|
| At some point you come to a level where approximately 0%
| of the w3schools pages contain the information you need,
| but 100% of the MDN pages. So.. why have the overhead of
| w3schools results? Also, why develop bad habits early on?
| cubefox wrote:
| I'd say w3schools is actually much better for beginners
| than MDN. If you learn HTML, CSS or JavaScript, MDN will
| often include too much unimportant information. (Similar
| to how Wikipedia math articles are often inscrutable for
| beginners because they are littered with lots of advanced
| low-importance information.) Additionally, w3schools has
| more easy "try it" examples which MDN consideres too
| trivial to bother with.
|
| I agree though that MDN is much better than w3schools for
| non-beginners.
| hju22_-3 wrote:
| Any reason not to mention which search engine you use?
| leadingthenet wrote:
| I'm not him but Kagi supports this functionality, and I
| make heavy use of it. Incredibly useful.
| Phemist wrote:
| To put the focus on the principle of controlling your
| search engine results, rather than the specific tool
| (which is Kagi btw)
| IshKebab wrote:
| I disagree. It's very good. Far above average. But there's
| still a decent number of times I find missing details.
|
| If we're talking the _best_ then it has to compete with Qt,
| Rust, MSDN, cppreference, all of which I would say are better.
| Definitely in the top 10 though.
| raincole wrote:
| Especially considering they are facing an unusual hassle:
| browsers' compatibility (which is completely out of their
| control).
| dgb23 wrote:
| It's not only a great reference documentation, it also has
| comprehensive guides for both beginners and advanced
| developers. Including niche/complex features like canvas,
| webrtc, service workers etc.
|
| In a web programming course I created I often referred to and
| leaned on MDN.
|
| Aside:
|
| DDG lets you search in MDN directly if you prefix a search with
| !mdn. It's one of the few sites that has a very much usable
| search feature.
| edlucas wrote:
| Kagi search also supports this bang shortcut, which I find
| very handy.
| thrdbndndn wrote:
| I do found more minor errors in MDN compared to other official
| documentation (like Python), but it's kinda understandable.
|
| And it sometimes takes months to get things fixed (after
| reporting or providing PR at https://github.com/mdn/content).
|
| I've learned to always test myself when it comes to
| pesky/obscure behavior(s) of JS.
| timvisee wrote:
| Then you haven't seen Rust's documentation yet.
|
| https://doc.rust-lang.org/std/index.html
| lytedev wrote:
| I'm partial to Elixir's documentation myself:
| https://hexdocs.pm/ecto/Ecto.html
| sjsanc wrote:
| Compare MDN's entry for the `map` method
|
| https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| With Rust's
|
| https://doc.rust-lang.org/std/iter/struct.Map.html
|
| I find MDN to be a bit clearer, and they benefit from the in-
| browser runtime. All the extra detail in the Rust docs
| (blanket traits etc) were quite intimidating and distracting
| when I first started learning it.
| ndriscoll wrote:
| You linked to the docs for the result type of `map`,
| not`map` itself. The method is here:
|
| https://doc.rust-
| lang.org/std/iter/trait.Iterator.html#metho...
| timvisee wrote:
| That MDN page has a lot of noise and is not straight to the
| point. I guess that may be a side effect of JS though.
| recursive wrote:
| Where's the noise? I'm not seeing any.
| lucideer wrote:
| While both of these docs are pretty good, as someone who
| normally _much_ prefers API references to "how to"
| formats, the MDN's "how to" approach here is succinct &
| just enough to cover reasonable bases, while the Rust API
| ref list is a bit too terse by comparison (& the Read
| More click out is a bit annoying).
| bsmth wrote:
| Thank you for sharing, feedback like this is a great to see :)
| spread_love wrote:
| Freemium teaser?
|
| I'd monetize this by adding features and hiding them behind MDN
| Pro+ (or w/e the subscription is called) in the future. Ala
| Codepen.
| max23_ wrote:
| Nice to see this from MDN. My go to playground has been jsfiddle,
| will start using this.
| fiji-flo wrote:
| Here's the announcement blog post for some context:
| https://developer.mozilla.org/en-US/blog/introducing-the-mdn...
| ogaistan wrote:
| I really spend more time than I thought I would be (in this age
| of JS frameworks) using dead simple HTML, CSS, JS playgrounds for
| quick prototyping and iteration.
|
| I did eventually end up building one for myself and made it
| available [1] that the goal was a clean UI/UX, minimal and
| instant live feedback loop with no extra calls to the server -
| just a simple static website. It defaults to a JS playground
| since it's what I use the most but HTML and CSS can be toggled.
|
| [1] https://www.jsplayground.dev
___________________________________________________________________
(page generated 2023-07-20 23:02 UTC)