React Spike: Rewrite the MDN page header #967
Comments
Why does everything seem to need to be written using React these days? It honestly feels like trying to fit a square peg into a round hole to me at this point. In other words, I don’t feel like adding React to MDN would be much help, and might instead make things harder to maintain. |
@ExE-Boss: some of our reasoning for using React is captured in this ADR: https://github.com/mdn/mdn/blob/master/ADRs/001-use-react.md In my experience, React makes front-end development easier. We anticipate having to do a lot of it in 2019, so trying to move to React now will increase our development velocity for the rest of the year, we hope. |
I would also like to point toward hyperHTML, which I didn’t see mentioned on the page.
See also mozilla/dispensary#465 |
FWIW, W3C Respec has been using hyperHTML for more than a year: And ABP ships with HyperHTMLElement and hyperHTML to roughly 100M users, targeting FF, Chrome, Opera, and Edge 👋 |
Just my 2c, as someone involved with browsers and standards for the last ~13 years. Libraries come and go, and generally all libraries/frameworks have a lifespan of about 5 years (there was some data published by GitHub about this, I believe, that made a pretty compelling case). In evaluating a solution, be sure to consider the library dying out or becoming a maintenance burden after 5 years (e.g., everyone trying to get off jQuery onto Web Components). In the case of ReSpec, we chose HyperHTML because it's "so close to the metal", super thin and - it's extremely standards conforming and a library that can be used without build tools, and could easily be used for another 10 years with no problem. Before choosing React, or any library, please consider if the MDN project will be around in 10-20 years (I believe it will be) - so these technology choices REALLY matter. Please choose wisely. |
If you feel the need to do something with the header in JS, then I would opt for a WebComponent based approach and, if using React, wrap the React in https://github.com/rstacruz/remount to make it a WebComponent. That way the rest of the site don't have to care whether it's React, LitElement, vanilla WebComponent or whatever and you can independently update and/or replace component implementations independently from one another without any of them having any other public API than the webcomponent they are exposed as. We're taking this approach at our sites as we recognize that some highly dynamic parts would benefit from something like React, but we don't want to require React on page loads with no such highly dynamic parts and don't want to couple all of our code to a single library. Combining such a structure with something like Webpack and code splitting enables standard webcomponent based interfaces, sharing of libraries between webcomponents as well as loading of heavy libraries only whenever a webcomponent requiring that library is used. |
WHYYY!? Why React!? Why not web standards!? Why not Web Components? It's a shame. |
This is simply untrue and somewhat disappointing reasoning; web components are supported by all major browsers*. The Polymer Library has been put in maintenance mode, but there's a wealth of web component libraries out there now, LitElement, Ionic, etc.
I agree that the web component ecosystem isn't as large as React's, however we've been doing a bunch of work to improve this situation and make things easier for developers on any scale: www.open-wc.org I feel like it's a little disappointing, especially from MDN, to not go with web standards. I do hope you reconsider.
|
Looking at the MDN header, there is a perfect use case for You could avoid using Shadow DOM for such a small thing, and only use Custom Elements part of the standard, same as GitHub does (which would make a lot of sense for this particular case). |
As representatives of Mozilla, standing for and promoting the use of open web standards, we should be more diligent about our choice of technology. It comes under increased scrutiny and it sets an example to the people we intend to educate on the importance of open web standards. It's not that React is bad. We use it elsewhere on other properties as mentioned here. But for MDN itself, choosing to overlook Web Components, which as commenters above point out has widespread support, impacts our message. This React rewrite looks like an experiment for now. Which is good. Learning is good. But I echo @marcoscaceres' thoughts and sincerely hope you'll consider carefully the implications not just the how when approaching the MDN rewrite. Regardless of the technology used now, it will be eventually rewritten in the future. Frameworks come and go. Being closer to the web platform matters more in the long term. |
I'm a huge fan of MDN, and vigorously support your work. In addition to all the above: Inherent Benefits of WC Over React Pedagogy Developer Experience So we all agree that components that render DOM as a pure function of state are a great way to develop. So, the best resource on the web platform should do that with the web platform. React Approach Hostile to Web Standards, Thus Inappropriate for Mozilla React's approach very much aligns with the view that the web platform is a problem to be worked around and abstracted over. In the "react way", the browser is merely a compile target - one of many among native apps, etc. I don't think Mozilla should be encouraging that view by encouraging the use of React. Lastly, it strikes me (personally) a little funny for Mozilla to investing so heavily in Facebook's tech stack. React is a fine library, but using it on MDN just strikes me as odd. |
@davidflanagan I think it's perfectly fine to choose React for a project, so I don't want this comment to seem only anti-React or only pro-Web Components, but I noticed in the ADR some incorrect information around Web Components, and it would be a shame if a decision was based on false background. Specifically:
Unfortunately, this whole paragraph is basically untrue. It seems like it was written based on information from 2 years ago. Web Components (<template>, Custom Elements, and Shadow DOM) are supported in Chrome (and all Chromium browsers like Opera, Android, and Samsung), Safari, and Firefox. Safari has had support for almost 2 years, and Firefox since 63. Firefox is porting it's actual UI from XUL to Web Components as we speak. Also, Polymer is far from the only option for writing web components. Stencil (from Ionic) and SkateJS (which can use Preact, React, or lit-html to author components) are two popular libraries. Angular, Vue, and Svelte are working on Web Component output. The Polymer Project itself just released LitElement, which is a very React-style approach to writing web components, but without any proprietary JS syntax extensions or required build steps. I encourage you to check it out if you like the React experience and are even the slightest bit interested in Web Components in the future.
What tool support are you looking for? Projects like LitElement have great tool support because they're just JavaScript libraries. There's no special syntax or build requirements, so they work with all the existing tools like Webpack, Rollup, Parcel, Babel, ESLint, TypeScript, Workbox, etc... Older versions of Polymer used HTML Imports instead of JavaScript modules, and therefore had to have custom tools or plugins. This hasn't been the case since Polymer 3.0 though, and Polymer is also now compatible with all the standard ecosystem tools. I really hope that the ADR can be corrected to reflect the actual state of Web Components, and that the decision here, even if it's to move forward with React, can be based on accurate information. I'm glad to help in any way that I can. |
Ditto. I'm ready and willing to help implement with lit-element or another modern web component library. |
I would personally prefer to use hyperHTML or lighterHTML since they have a few extra features that lit‑html lacks, which my code depends on. Also: |
I can help with code using hyperHTML i think is the best route |
Since we're proposing standards based alternatives, and since the React choice looks to me somehow rather motivated by boredom of using just standards, here my counter list:
All these variations based on Web standards, and delivering just those, are the attempt of a long standing Web standards promoter as I am, so that surrounding hype can easily lower when you see you can achieve great results simply respecting, and using as much as possible, the Open Web Platform, the one Mozilla should have as part of its mission. Please do not ever ditch the platform on a site that promotes it. Thank you. P.S. obviously happy to help as I can if it's needed 👋 |
lighterHTML is to hyperHTML what Deno is to Node. Also, there’s a PR for adding React as a dependency to Kuma now: mdn/kuma#5250 😞 (please don’t spam comments on that PR, as that would be unprofessional) |
Ease of experience for developers should not trump the experience of end-users. The added code-weight, complexity, and chance for things to fail are strong reasons to serve up as much in good old HTML as possible. Maybe a SSG augmented with some light JS? |
I should add, I'm all for ripping out jQuery from things. But these days, some progressive enhancement, native JavaScript, and polyfills (automated, even, from polyfill.io) do a lot. |
I won’t comment on the rest of this thread. But the notion that React is somehow antithetical to standards is very misinformed. We’re thrilled to collaborate with vendors on specifications that advance the future of the web. That includes ongoing work on user interface responsiveness, display locking, main thread scheduling, and other initiatives like virtual scrolling APIs. Some of these collaborations are currently driven by Chrome but we’ve worked with Mozilla, Apple, and Microsoft too on the topics where they were interested in our input. Having worked on React, we’ve accumulated some experience that we are excited to share with the broader web community. There are valid criticisms like subpar support for custom elements, but again, it is not due to a lack of care. Rather, there are many unsolved questions that even the community actively using web components today can’t reach agreement on. (Related to heuristics for properties/attributes and server rendering.) We take API changes in React seriously so we want to ensure that if we change the behavior, we won’t have to change it again in a few years. I hope that you can empathize with such approach. You’re welcome to contribute to the discussion about specific issues on the React issue tracker. We care about moving the web forward, and not just React alone. We don’t always agree about which specific standards or techniques will help folks create better user experiences for the web. That is a source of much tension in some communities. But don’t mistake disagreements with a lack of enthusiasm. React is firmly built on the web platform and standards, and will continue to be. |
That's one way to put it. Another way is that we can't get agreement on heuristics because heuristics are bad and it would be great if users could just specify whether they're setting an attribute, property or event handler in JSX. Framing this as the web components communities failure to agree is misleading, IMO. |
@gaearon I don't think any of the above is criticising React or is necessarily misinformed. It's simply pointing out that it isn't required in this instance. It's like using a steel-mill hammer to knock a thumb-tack into putty. Sure, it'll work – and it might be the most poweful hammer in the world – but it's overkill. Tools like React (and your own tool, Redux) are great, but there is a creeping tide of people using tools like it in places that it simply isn't required, or appropriate. A big part of this is down to people working on projects it isn't required on feeling like they're being left behind, rather than recognising they are working on projects that don't need it, as well as people working with the tool irresponsibly praising it without noting where it is appropriate to use it. Sites like MDN are a standard bearer for technologies that are used on content-focused websites like itself. If we start adding React for reasons related exclusively to the development experience, then we risk sending the message people should be using React – or other similar tools that are intended to solve problems complex web apps suffer from – for other content-focused websites. |
Thanks for the constructive comments everyone. I'm glad to hear that web components are more viable today than I realized. I'd love to have the opportunity to work with web components. But that is not an option for MDN. The MDN engineering team is very small, but we have ambitious goals for 2019. (These goals are not yet ready to share here, so you'll just have to trust me on this.) We're expect to be doing a lot of front-end work this year, and also expect that we're going to have to hire contractors to help with this. There are likely to be an order of magnitude more webdevs with top-notch React skills than we would be able to find for web-components based solution. It is not like we've just made the decision to switch to Flash! Nor are we announcing that we're going to start using closed-source solutions for our front-end work. Instead, we're picking a technology that we believe will allow us to most quickly deliver features to our users. And that has to outweigh concerns about the purity of the solution. The particular user story that this thread is one of the things I'm working on this month. A kind of proof of concept, to see if I can determine the performance impact of replacing the jquery library with react, and to figure out whether we're going to have to jump straight to server-side rendering before we ship anything React-based. If it turns out to be an utter failure, then we'll reassess. The point here is to improve our user's experience with MDN. We're not going to let MDN turn into a big bloated thing. Your trust would be appreciated. |
I agree with this, and I also want to add that MDN is a website specifically for web developers, and by being made using standards, it's currently very easy to just right‑click and select “Inspect element” and have it just work without needing to install a 3rd party DevTools extension for the browser to be able to understand React’s VDOM. |
Hi @davidflanagan - thanks for the thoughtful response!
Apologies if this felt like a criticism of you personally. Rather, it's a comment on React as a platform itself. I trust you to do the right thing, but React is a big beast with a mountain of front-end baggage attached. As a side note, starting this thread with "so I can gain experience using React" probably gave people the impression the motivation here was for learning purposes rather than for any meaningful gain to MDN as a platform. Thanks for adding more details. |
@gaearon for a second, imagine this wasn't about React, and the TL;DR version of this story is: We're refactoring a working "vanilla" jQuery to bring in a framework that needs mandatory transpilation step due to non standard syntax (JSX, not Babel which aim is to fix standard gaps), a framework that easily ditches semantics and simplifies inline style per element, on the #1 stop to learn about Web Standards. How would that feel to you? |
How does this affect the accessibility story? |
I'm really happy to see the MDN team making decisions and documenting their process in public It's really disappointing to see the pile-on in this thread about their decisions 💔 I wish success to the MDN team, and look forward to seeing what 2019 brings (it sounds exciting 🤩). ⚛️ |
MANY OF THE PEOPLE IN THIS THREAD SHOULD BE ASHAMED OF THEMSELVESThe MDN team has built the single greatest resource on the web for web developers. Thousands if not tens of thousands of hours of work have gone into building it. And this is somehow not enough for you? Screw you. The MDN team can do whatever [redacted] they want and we should all [redacted] while they do it. We should offer every ounce of support our sorry asses can possibly muster for any effort by the MDN team to make their lives easier. And we should leave it to them to decide what they think will make their lives easier. That is all, [redacted] if you disagree. |
before this thread gets deleted thanks to people incapable of respecting any netiquette, I'd like to say this last thought on this matter. Imagine Brendan Eich using TypeScript so that nobody would keep betting on JS. The message that the No. 1 resource for Web development is ditching the same Web technologies it advocates, would be as disastrous as that, implicitly claiming a defeat for the Web, hence a seppuku in the long term for the platform nobody would care much anymore. When MDN used jQuery to create anything, the Web was in an objectively poorer state. I don't even care if MDN would use any of the libraries out there, quite the opposite, I actually would love to see it embracing raw Custom Elements like never done before, so please think about the heavy repercussion this decision would have. This is not about React per se being a bad tool, this is about every Web Standards advocate that would indeed feel ashamed at pointing at a resource that didn't use its own product. If using frameworks is instead seen as mandatory due big plans, then please stick on this header: "whatever you'll learn here won't be useful on the real world unless you are a React core developer" so that people can change site and learn something more useful instead for their own career sake. Thanks for considering improving the message. |
Literally search "brendaneich typescript" and you can see him advocating TypeScript again and again. He also helped spec WebAssembly and modified "always bet on JavaScript" to "always bet on JavaScript/WASM" This whole argument is just is entirely inauthentic. |
Here, meet the mighty Brave browser and see they use JavaScript.
I have helped with other specs for JS, not sure I understand your point there ... WASM is also not code for developers to learn or write, so again, what is this reply about?
Your attitude full of insults and bullying is, instead, super smart and mature.
I've worked at Facebook with the team that published React later on. I know React before you could know it existed. If you'll ever be interested in knowing why, at its debut, I hated React, I'd be happy to explain it to you, but differently from the React tribe, I've never made it personal, and I'd never shame anyone or anything in public.
And again, premium for the genius of the day goes to you, right? My libraries are so stupid that unlocked Custom Elements for Google AMP, StencilJS, AFramework, among others, and unveiled the hidden power of keyed DOM through template literals. Every single library I've written was to promote the usage of the platform for every skeptical thinking the platform wasn't fun, wasn't capable, or wasn't ready. Glad other projects followed up, see lit-html, as example, and glad not everyone is as immature and irrespecutful like the last two developers from the React community. Best Regards. I wish there would be also some moderator in here. P.S. just to clarify how much I hate React as the React community imply, this is from my Neverland debut post (previously linked, no need to spam). |
@WebReflection Please don't say this:
That person always have a bad attitude at everything and it is not a representation of the React community. |
@montogeek I have pointed at a whole twitter thread started from a Facebook employee full of even worse attitude and bullying than the one you found in here. |
Really? All of this to output basically a content site? Even if considering only client side, React without its ecosystem is not very useful. So i would not be surprised if MDN will depending on redux, react-router, a third party datetime/search component etc
The learning curve to using web components is pretty flat, since is just standard JS class with a few callback hooks, everything else can/should be accomplished with native web platform, so i don't see React proficiency as a strong argument All in all just like to highlight a recent article on Mozilla Hacks, by @potch, calling developers to unleash the power of web components:
If web components are not suitable to a primarily content site, with a few dynamic interactions it should be for my complex app? If web components are so hard to be proficient in (more than a non standard, own world library) should i really invest in it? So, Mozilla does not believe in what they write? In my opinion, none of the above statements about web components are true but sadly this is the message Mozilla is passing to web developers with this decision |
Can we have a discussion about the pros and cons of the approach to design
without devolving into personal attacks?
I would recommend either closing this issue or removing the posts that
violate our CoC.
…On Fri, Feb 15, 2019 at 8:04 AM Luiz Américo ***@***.***> wrote:
In context of backend html rendering using Python I could propose this
possible solution for this:
Really? All of this to output basically a content site?
Even if considering only client side, React without its ecosystem is not
very useful. So i would not be surprised if MDN will depending on redux,
react-router, a third party datetime/search component etc
David has 18 months experience with it; Schalk was already learning it.
The learning curve to using web components is pretty flat, since is just
standard JS class with a few callback hooks, everything else can/should be
accomplished with native web platform, so i don't see React proficiency as
a strong argument
All in all just like to highlight a recent article on Mozilla Hacks
<https://hacks.mozilla.org/2018/11/the-power-of-web-components/>, by
@potch <https://github.com/potch>, calling developers to unleash the
power of web components:
Custom Elements have already been used to make it easier to build VR
content on the web, spawned multiple UI toolkits, and much more. Despite
the long standardization process, the emerging promise of Web Components
puts more power in the hand of creators. Now that the technology is
available in browsers, the future of Web Components is in your hands. What
will you build?
If web components are not suitable to a primarily content site, with a few
dynamic interactions it should be for my complex app?
If web components are so hard to be proficient in (more than a non
standard, own world library) should i really invest in it?
So, Mozilla does not believe in what they write?
In my opinion, none of the above statements about web components are true
but sadly this is the message Mozilla is passing to web developers with
this decision
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#967 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKC-pksCLYL1ZvfIRE8QFMSNB-XUBuXYks5vNrBbgaJpZM4amRE9>
.
|
I’m interested in hearing about it, but you probably should make it a post on your blog, rather than a comment here. |
Someone want to help me find Brendan Eich on this list? https://github.com/brave/brave-browser/graphs/contributors Also apparently Brendan Eich thinks we should all use C++ because apparently the code other people write is more indicative than his own words https://github.com/brave/brave-core |
As a reminder, the Code of Conduct for this repo references the general Mozilla Community Participation Guidelines (CPG) and the specific Developer Etiquette Guidelines (DEG). The CPG includes the following:
The DEG also recommends "No whining about decisions" (though in a different context). |
@jmswisher thanks for the concise reminder and summary. If I can clarify anything, at least from my side, is that decisions have been taken not in the public, and this is the first public place to communicate our concerns about such decision, made over an outdated, and misinformed, ADR document. Mozilla employees have of course the right to do whatever they want, but if they choose a direction that somehow fails to represent what's MDN is about, it's not really whining, rather hoping there's still a remote possibility to change such decision. Since the main developer that should be interested in working, and hearing, in the open, is purposely ignoring this thread, I guess we can close this to avoid further irrespecutful comments 👋 |
This is the saddest part of all of this. Again i'll take some words from Mozilla, this time from Mitchell Baker in an email asking for support:
So here i'm, trying to make a relationship with Mozilla and help, in my understanding, create a better web, free of non standard stuff. Just to be ignored. |
This entire thread is hilarious. If you're THAT mad about what framework they use to make their website, you can always just use w3schools instead 🙂 |
Can we please close this thread to avoid previous kind of irrelevant comments that would pointlessly notify everyone? |
Its Friday afternoon. I'm going to try to bring some closure to this thread without, I hope, stirring up more controversy. And then I'm going to try to put this behind me and get back to work next week.
Respectfully, David Flanagan |
@davidflanagan ( just to be sure you'll read this 😄 ) I won't go answering point after point 'cause you have the rights to spend a peaceful weekend, and put this week behind, but I still think the message this will send will have bad repercussion for the Web development in the long term. I've worked in 20 years from small, to medium and big projects (including FB and Twitter), and with the plethora of tools available these days, I don't buy this productivity boost you are mentioning, simply because if you need indirections to represent the Web after all, you're putting an extra layer on top, not one less. Regardless, I do agree tools, including programming languages, are a matter of personal taste, so that selling these as "the only way to scale and develop medium size Web projects" should rather be kept underlined as highly subjective too. In any case, I do really appreciate your time to properly address most comments and better describe what is this repository about (I work in the Open daily too, I can't imagine handling threads like this while we make decisions for our product specs) so, in few words, thank you. |
A lot of ppl suggesting web components are missing the point, let devs choose the tech they want to keep them engaged and productive specially when web components are extremely dreadful to work with, at the end of the day the tech doesn't matter, what matters is the end result, and if the team is happy and have a choice of the tech stack, they should write it in whatever they like. |
Some MDN devs are still learning React (this info was deleted in OP), so being productive is not certain
This is opinion, many find React to be dreadful and think web components are " the tech they want to keep them engaged and productive"
This is debatable, see above comments, but will not counter argument (again)
Very true. Given the nature of project (and defined objectives) React seems not appropriate, with some caveats waiting for the devs. Let's see what we will get in a few months |
@blikblum An engaged developer is always more productive and a motivated team put more effort and hours into the project while having more fun. The fact MDM guys are still learning react is also what driving the whole thing, to use opportunities to learn new tech in practical environment. I work for google and 3 month's ago for the first time in years I was given an opportunity to select tech stack for a pilot project, never seen the team so driven and excited before, the tech stack was GO+React. btw just FYI the way opinions work is that everything I say is my opinion, no need to select one particular statement :) |
@AlekzZz no problems with React or Angular or Backbone or nothing at all, specially for projects starting from the ground with few upfront constraints. In my opinion, with the declared objectives (feel free to read above), the number of challenges integrating React will be no negligent. But leading with those challenges is part of learning process. As you said, what matters is the end product, so let's see in a few months were this will end. |
Wait... is this whole conversation about just making the sub-nav in the header open on click instead of hover? Seems like a couple of lines(literally just toggle some class names) of vanilla js would do that easily. Why would you bring in a any framework to do that? I feel like I've missed something. |
@davidflanagan One thing you'll find rewriting the header is there is going to be some tricky logic dealing with React synthetic click/keyboard events and actual DOM events clashing a bit when you click on a React drop down element and a non react element. Happy to help if you get to that point. |
Wow never thought about the learning perspective and letting people
contribute, whether paid or volunteer, to also build in a way to support
their goals.
Important point to consider.
…On Thu, Feb 21, 2019, 1:25 PM afr114 ***@***.***> wrote:
@davidflanagan <https://github.com/davidflanagan> One thing you'll find
rewriting the header is there is going to be some tricky logic dealing with
React synthetic click/keyboard events and actual DOM events clashing a bit
when you click on a React drop down element and a non react element. Happy
to help if you get to that point.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#967 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKC-pvhTHJwO6vGGktoI19ZJO6LdnQqiks5vPuSQgaJpZM4amRE9>
.
|
Random advice from a random dev 😎 : I've always struggled with chosing the right technology. But then sometimes you just have to go in and do the job. But if you are consistent, you can just remove the fear of bad choices knowing you have something like jscodeshift (sorry haters, it's another facebook library) and change everything with peace of mind. Edit the transform, run it, check results, Just go with whatever you want, be consistent, and you can, if you want it, just shift everything if you aren't happy with the result. Go from mocha to jest, jest to mocha, react to mithril, mithril to snabbdom, react to hyperhtml, rxjs to mostjs, jquery.ajax to superagent, pattern to pattern. If there's a pattern, you can find & transform it. Go nuts This concept of coding editing code for me changed my life as a developer. I truly hope it becomes available, in one form or another, in all available languages. TL;DR: Go nuts with react, jscodeshift has your back if you change your mind. |
This is working on the staging server, which is as far as we're planning on taking it for now, so I'm closing the issue. |
User story
As an MDN developer, I want to rewrite the MDN page header using React, so I can gain experience using React for a non-trivial page component, and so that I can reduce our the dependencies on jquery.
(Also, as an MDN user, I don't want the menus at the top of ever MDN page to appear every time I move my mouse pointer near them.)
See https://bugzilla.mozilla.org/show_bug.cgi?id=1525719
This issue is intended to be tacked after issue #965 and issue #966.
The goals of this work are:
to do a non-trivial chunk of React coding, to help ensure that the toolchain we're using is suitable
to prototype a positive UX improvement for the site (fixing the menus so they require a click to display)
(stretch goal) to see whether we can remove the jquery dependency from the main.js file that is loaded into every page - this would also mean replacing the footer and other parts of the wiki page with React-based alternatives.
Acceptance criteria
The text was updated successfully, but these errors were encountered: