React Spike: Rewrite the MDN page header

[davidflanagan]

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

• [x] Wiki pages loaded through the new endpoint (see issue #965) have a React-based header
• [x] The menus in the header do not appear on hover!
• [x] We have synthetic page load data comparing the new header to the old header

[unclechu]

@davidflanagan If you're going to rewrite MDN using React I assume it's going to require enabled JS to render any content so it would make it impossible to obtain any content as a static data which is sad by my opinion. It can be solved by Server-Side Rendering (SSR). If you haven't planned implementing SSR by yourselves I'm offering my help with that (since I'm experienced with that) as a volunteer. I could afford some time to at least produce a backbone for SSR. Feel free to contact me if it would be a good idea.

[davidflanagan]

Thanks for offering @unclechu. One of our goals this sprint is to at least try SSR. I have not set that up before, and would welcome some pointers. To start, however, we're going to have a little bit of react inside of jinja templates, and I don't know whether SSR can work in that situation.

Once https://github.com/mozilla/kuma/pull/5254 lands there will be something concrete to try rendering on the server, if you want to take a stab at it!

[Tbhesswebber]

I think that this is some really great discussion, but people are having a hard time separating their experiences and heresy from fact about "the other side". "Div everything" is as standard for developers as seeing <some-component> in the DOM is semantic. Neither side is "right" and both React and Web Standards are as likely to change in three years as the other.

At the end of the day, none of us should care what MDN uses - we should care that the devs who have put so much effort into building a resource that has massively contributed to our own education and will continue to do so on a daily basis are productive and happy.

I will, however, leave this here for people to pontificate upon... 2018 State of JS (web components, in general, are under the "Other" page...)

[ExE-Boss]

@davidflanagan

To start, however, we're going to have a little bit of react inside of jinja templates, and I don't know whether SSR can work in that situation.

React doesn’t work all that well with Jinja and other non‑JavaScript SSR solutions well from my experience.

This is because there’s no React for Python, and React works using its VDOM, whereas Jinja2 and similar assume that they’ll be outputing pure DOM, which is a bit difficult to wire with React.

But if you really want to use React, I at least recommend using https://github.com/rstacruz/remount, which creates a React environment inside a Custom Element, so that React doesn’t leak into non‑React scope, which is a possibility.

Plus, custom elements already work with Jinja2, given that they behave like normal HTML tags, except that they have at least one - in their tag name.

[unclechu]

In context of backend html rendering using Python I could propose this possible solution for this:

1. Writing a process in node.js (with React SSR stuff inside) which reads something like JSON-commands from stdin and returns to stdout rendered html code using React SSR;
2. Starting that process from Python as child-process permanently;
3. Asking from Python main process to render something from node.js process and reading result from stdout.

Also it would be better to run few SSR workers and balance requests between them. Maybe there's some python lib to serve such queues? Or as an alternative we could run SSR processes (workers) as a local-hosted HTTP-servers and balance them with local nginx-proxy, and from main Python process request renders via HTTP. But of course using HTTP layers adds some overhead and forces us to control SSR-workers apart from main Python process.

[antmak]

React makes front-end development easier.

We need to make user experience easier, not development.

[vipickering]

In particular the statement here(highlighted in bold) made me sad.

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.

While I respect your decision (you understand your needs/constraints better than I do) I find it sad that web standards are being over looked for custom frameworks.

This means you are doing the same thing other companies are doing and overlooking Web components for React; Systematically alienating the standard for a custom tech which becomes self-perpetuating. If we don't use these technologies at scale we dont uncover the problems and learn how to fix them. Every time a large entity in a privallaged position chooses custom tech over the standard it takes us one step closer to a non-standardised world.

[jgmac1106]

MDN is going to React???? The day you can't hit "View Soucre" and see human readable data on Mozilla web documents will be the day the Manifesto truly becomes meaningless

I'm not angry really sad. MDN is supposed to be the model of web standards.

Mozilla employees are like frameworks they come and go but HTML is forever. Choosing a framework because a team knows it wrong.

You need to be hit "view source" and read not see a much of scripts. Greg McVerry. I know folks say well MDN code will be available in the repo. In my browser window when I hit view source, if the mission is equity and access....sayign "here's the repo" is not the same. Mozilla teachers throguh source code not frontend frameworks

As a contributor to MoFo and MoCo I have seen this story play out and always looked to MoCo and MDN with the commitment to HTML first as a north star

MoFo would be all about the latest and greatest framework trying this and that making resources harder and harder to remix (they very essence of what being open means) while MoCo always held firm. Always stayed committed to an open human readable web.

I worry those days are over

Look at MoFos track record of developing software and platforms literally every single one is gone and failed. Look at anything Mozilla has done in HTML. It is still there. Forever

Every existing product built on REACT is a MoFo project and almost every single one is marked for sunsetting and deletion.....

We have enough data to know this is a failed path. Like every time we tried.

Go read the top reason for choosing React:

David has 18 months experience with it; Schalk was already learning it.

Choosing to abandon the open web because one person on staff knows it is a bad idea. Employees will not last longer than HTML.

Web components will eventually be the standard component system for the web,

NO! Web components ARE a standard and an OPEN standard. They only survive in the face of corporate greed when Mozilla stands up.

The MDN has ambitious goals for 12019 that we can't share.

When did Mozilla lose its attitude to open? This shift to React and away from the open we reflects a turn away from open contributors and a disdain for Mozillians who want to contribute. We are just seeing another example of Mozilla turning our back on the Manifesto.

I mean @davidflanagan MUTED HIS OWN THREAD basically saying we don't care what the community thinks. We are Mozilla we make software FOR open source contributors but we no longer have any desire TO BUILD with open source criteria.

I know the team feels JQuery and javascript present limited choices fro complicated UI (so use less), and I won't hype web components more than they are. , I struggle with front end design as well battle every, but I made a promise to the open web. Mozilla should do the same.

We need to work together but r to make it better using open standards in a web first way, will always support MDN...but just hope I can still click "view source" and not see gobbily gook

[jesstelford]

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 🤩).

⚛️

[jamiebuilds]

MANY OF THE PEOPLE IN THIS THREAD SHOULD BE ASHAMED OF THEMSELVES

The 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.

[WebReflection]

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. Choosing in 2019 frameworks after all the innovation and effort put in browsers alignment with standards, doesn't sound rewarding for all the people that contributed with the MDN content that explains all these new amazing opportunities to develop through Open Standards.

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.

[jamiekyle-eb]

Imagine Brendan Eich using TypeScript so that nobody would keep betting on JS.

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.

[WebReflection]

@jamiekyle-eb

Literally search "brendaneich typescript" and you can see him advocating TypeScript again and again.

Here, meet the mighty Brave browser and see they use JavaScript.

He also helped spec WebAssembly and modified "always bet on JavaScript" to "always bet on JavaScript/WASM"

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?

This whole argument is just incomprehensibly stupid

Your attitude full of insults and bullying is, instead, super smart and mature.

Andrea just has been salty about React for years because ...

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.

... because he'd prefer people use his stupid libraries.

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).

[montogeek]

@WebReflection Please don't say this:

The attitude of the React community full of insults and bullying is, instead, super mature.

That person always have a bad attitude at everything and it is not a representation of the React community.

[WebReflection]

@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. Their representatives should lead the way not only from a technical point, but from an ethical one. If there were a moderator, those two message would be either edited or removed. I'll correct that sentence regardless, but the feeling remains.

[blikblum]

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, by @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

[jgmac1106]

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 notifications@github.com 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 https://github.com/mdn/sprints/issues/967#issuecomment-464043715, or mute the thread https://github.com/notifications/unsubscribe-auth/AKC-pksCLYL1ZvfIRE8QFMSNB-XUBuXYks5vNrBbgaJpZM4amRE9 .

[ExE-Boss]

@WebReflection

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.

I’m interested in hearing about it, but you probably should make it a post on your blog, rather than a comment here.

[jamiebuilds]

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

[jmswisher]

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.

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:

Direct but Professional We are likely to have some discussions about if and when criticism is respectful and when it’s not. We must be able to speak directly when we disagree and when we think we need to improve. We cannot withhold hard truths. Doing so respectfully is hard, doing so when others don’t seem to be listening is harder, and hearing such comments when one is the recipient can be even harder still. We need to be honest and direct, as well as respectful.

Understand Different Perspectives Our goal should not be to “win” every disagreement or argument. A more productive goal is to be open to ideas that make our own ideas better. Strive to be an example for inclusive thinking. “Winning” is when different perspectives make our work richer and stronger.

Personal Attacks Conflicts will inevitably arise, but frustration should never turn into a personal attack. It is not okay to insult, demean or belittle others. Attacking someone for their opinions, beliefs and ideas is not acceptable. It is important to speak directly when we disagree and when we think we need to improve, but such discussions must be conducted respectfully and professionally, remaining focused on the issue at hand.

The DEG also recommends "No whining about decisions" (though in a different context).

[WebReflection]

@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 👋

[blikblum]

Since the main developer that should be interested in working, and hearing, in the open, is purposely ignoring this thread

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:

People are asking, "The internet is broken, what can I do?" An important part of the answer is, build a relationship with Mozilla.

Make it as deep as you want. Sign up, ask your friends and family to sign up, donate. You should have a relationship with Mozilla. That’s where you can improve the internet as you improve your own experience on the internet.

We must demand better of the internet. And we must grow the number of people joining together with us to demand better of the internet.

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.

[kvnxush]

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 🙂

[WebReflection]

Can we please close this thread to avoid previous kind of irrelevant comments that would pointlessly notify everyone? Thank you.

[davidflanagan]

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.

1) This mdn/sprints repo is the MDN's team alternative to Trello and similar tools. As its name suggests, it is how we plan our work. Instead of creating cards on a private Trello board to track our user stories, we create issues in this repo. So we're working in the open, and anyone who wants to look over our shoulders can, but this repo is not really a place where we typically engage in debate or discussion about the user stories.

2) I tried to mute email notifications for this github thread and I also said that I didn't promise to read all of the comments. I see that many of you feel that this was insulting on my part, and I understand why that makes me look like a jerk. It was a mistake, and I apologize. As it turns out the joke was on me: I was never really able to mute notifications because I kept getting tagged by name and github started sending emails again. At this point, I think I have read more than 80% of the comments here. I have been tempted to respond to some of your comments individually, but fear of creating more controversy has stopped me. Please do try to see this from my perspective: imagine yourself at work, at the start of a new sprint, and out of the blue someone on Twitter links to one of the Trello cards assigned to you, and then dozens of people start offering you unsolicited opinions on how to complete your task. What do you do? Do you spend a day responding to the comments, or do you try to ignore the noise and carry on with your duly assigned work?

3) The decision to use React was properly made by the core contributors to the mozilla/Kuma repo. Currently that set of core contributors is the set of Mozilla employees who are paid to work on it. We do have occasional volunteer contributions, but we do not really have an active volunteer community around the Kuma server that drives MDN. (You all may not believe this, but I actually believe that using React for our frontend code may lower the barrier to entry for this project and increase our ability to attract volunteers.) My point is that the React decision was appropriately made by the engineers who are actively working on the project. It was never our goal to achieve consensus on this decision, nor would any kind of consensus be possible. I recognize that many of you are very passionate about web standards and about MDN, and I'm honored to be part of a project that inspires such passion. But your passion is not the same as working daily on a project (and having your annual review tied to the success or failure of the project!)

4) The decision to use React had not been communicated yet outside of the MDN team. We were not hiding it; we just hadn't attempted to announce it in any way yet. This is because we don't have anything to show yet. My work this month is to try to figure out how we are going to use React. This particular user story that we're all commenting on happens to be about the site header and menus, but only because I'm using that as a non-trivial proof-of-concept. The work this month is intended to remain on our staging servers and not be deployed to production. So while you may have been taken by surprise by this decision it is not because we were trying to be sneaky about it: there's just nothing there yet.

5) I used the decision about React as a test case for a new ADR (Architectural Decision Record) process for recording our decisions and the reasoning behind them. We're trying the process out and doing it in the open by default. It may nor may not work and we may or may not get any more ADRs checked in to the mdn/mdn repo. I'm hoping to make it a really lightweight process to encourage my teammates to make records of their decisions. My hope is that our ADRs will be a publicly readable record of our decisions. But if we find that we have to word them really carefully to avoid public controversy, then I expect that they'll turn out to be more trouble than they are worth and we'll drop them. When I wrote the ADR about React, I apparently misread the shadow dom v1 adoption stats on caniuse.com and stated that browser support for web components was lower than it actually is. I've corrected this in a superseding ADR. (It is still a pull request, but should land in the mdn/mdn repo soon.) The decision to use React still stands, but the section about web components is updated.

6) The majority of the commenters on this thread seem to dislike React. For the record, though, let's be clear that React is open-source and that React is a tool for producing websites that are built from the web standards of HTML, CSS and JavaScript. Yes, there are intermediate steps (jsx) that are not web standards, but the end product–the MDN website–is still based on standards. Its not like we're using Flash for our drop-down menus and an ActiveX plugin to display documentation in MS Word format! I'm guessing that many of you disagree, but I feel that a developers choice of tools–including frameworks–is a matter of taste. You may love vscode, but you're never going to get me to give up my emacs. And I may love React, but I'm not going to try to tell you that you should use it on your projects. Please don't judge me and my team on the tools we use, but on the quality of the websites we produce.

7) I love web components. I had the opportunity to use them just a little bit as the FirefoxOS project was wrapping up years ago. And I look forward to using them again some day. But: I spent 18 months using React at Khan Academy and found it to be a huge productivity boost. There is a reason that so many developers use React: it, and the mature ecosystem of tools around it, works really, really well for rapid frontend development. This may sound harsh, but if you haven't used React on a midsize (like MDN) or larger website, I don't believe that you are qualified to judge our decision. And if you haven't worked as a frontend developer in an environment where you've got product managers and user researchers and marketing teams asking you weekly to add features and A/B tests and banners to the website, then you're also not qualified to judge this decision, either. As I've said elsewhere in this thread, we're expecting to be asked to do a lot of frontend work on MDN in 2019, and it is our judgement that using React will maximize our chances of being able to complete that work. This is in part because it will make our core team (of 2 FE engineers) most effective. But also, by choosing the framework that is dominant today, we maximize our chances to find volunteers, contractors and consulting shops to help us when we need it. We haven't released a 2019 roadmap, and I can't talk about our plans right now in any more detail than that we expect to be doing a lot of frontend work. And so this also means that if you're not part of the core MDN team today you don't have enough context to understand our decision.

8) I hear your concerns about code bloat, tag soup and accessibility. Please remember that we are experienced professionals and we understand how to avoid those problems. (And as Dan Abramov pointed out earlier in the thread, there is a lot of FUD that blames React for those problems, when the fault really lies in lazy development practices.) We're not going to adopt React and then deliver web pages that are big and slow to load. I've also heard a number of you pointing out that UX trumps DX. I agree. But we've got a lot of UX to deliver this year, and we need all the DX help we can get from our tools. If React is the framework that is going to allow us to achieve our goals, then React is what we're going to use. And I've heard a number of you mourning the demise of view source. (I kind of agree, but I don't have any data to know whether anyone actually learns web development that way anymore, or if we're all just kind of nostalgic.) If we end up doing significant server side rendering of our React components, then much of the HTML source will still be viewable via view source. But even without SSR, React produces perfectly standard HTML and CSS, that is viewable (much more usefully than a static view source view) through developer tools.

9) Many of you have said that a website about web standards really ought to practice what it preaches and should use those web standards itself. I've already rejected the claim that there is something immoral or impure about React–it is a developer tool for producing websites based on standard HTML, CSS and JavaScript. But I get it: it would be really cool if the MDN website could push the envelope and be a public demonstration of web components (and other cutting edge technologies like service workers, for example). And if this was a personal project without a tight schedule, or if Mozilla was able to dedicate more paid employees to the job, then maybe that would be possible. I would honestly like to do that. But MDN's mission is to document web standards, not to demonstrate or dogfood them. Like any organization we've got a hierarchy and a planning process. We've got OKRs ("Objectives and Key Results") that guide our work for the year. And "Lead by example by adopting web components" is simply not one of our key results this year. If I thought it was the best way to achieve the results that are on our list, I would do it in a heartbeat.

10) Fundamentally, I'm asking you all to trust us. We're hoping to do great things this year with MDN, and I think that the vast majority of our users will love what we do. Thank you for reading this far, and thank you for your passion about web standards and MDN.

Respectfully,

David Flanagan

[WebReflection]

@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.

[AlekzZz]

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.

[blikblum]

let devs choose the tech they want to keep them engaged and productive

Some MDN devs are still learning React (this info was deleted in OP), so being productive is not certain

web components are extremely dreadful to work with

This is opinion, many find React to be dreadful and think web components are " the tech they want to keep them engaged and productive"

the tech doesn't matter

This is debatable, see above comments, but will not counter argument (again)

what matters is the end result

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

[AlekzZz]

@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 :)

[blikblum]

@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.

[tobz-nz]

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.

[afr114]

@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.

[jgmac1106]

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 notifications@github.com 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 https://github.com/mdn/sprints/issues/967#issuecomment-466110591, or mute the thread https://github.com/notifications/unsubscribe-auth/AKC-pvhTHJwO6vGGktoI19ZJO6LdnQqiks5vPuSQgaJpZM4amRE9 .

[Sinewyk]

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, git checkout, rinse & repeat until happy.

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 :shipit:

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.

[davidflanagan]

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.