The Third Age of JavaScript

Rate this content
Bookmark

The way we write JavaScript in 2030 will be completely different than in 2020. Here's why: the slow death of IE11 and rollout of ES Modules will converge toward a new generation of JavaScript tooling. These tools are faster, typesafer, and polyglot, leading to both a better developer and user experience. Change is afoot!

Shawn Swyx Wang
Shawn Swyx Wang
30 min
08 Jun, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This talk presents the Third Age of JavaScript, covering the evolution and future of the language. It explores the adoption of ES modules and the decline of IE11, as well as the changing landscape of JavaScript tooling and the concept of polyglot tooling. The talk also touches on the potential future of JavaScript with WebAssembly and emphasizes the importance of code composability and receiving feedback in software development.

Available in Español

1. Introduction to the Third Age of JavaScript

Short description:

I'm here to present the Third Age of JavaScript, which is a decade-long thesis. JavaScript can be divided into different ages, and I want to categorize and speculate on future themes. Today, we'll cover the First Age, the Second Age, and the components of the Third Age: ES modules, the death of IE11, polyglot tooling, collapsing layers of tooling, and potentially what comes after the Third Age.

Hey, everyone. My name is Sean, also known as swicksontheinternet, and I'm here to present this idea, this decade-long thesis that I have, that's called the Third Age of JavaScript.

So what's the story so far? You can sort of break JavaScript's periods up into two or three different ages. The First Age was from 1997 to 2007. There's a lot that was happening in 2008. There was a world crisis going on. So you could vaguely start picking things up again in 2009, going on to 2019. 2020 was another random mix of events, but there was still a lot of news going on. Now we're well into the 2020s. I want to talk about that. I want to try to categorize things in a neat little bow. Obviously, history is never as neat as historians put it. But we can actually talk about different themes and speculate on what themes are to come.

So the rough table of contents that we're going to cover today, we're going to cover the First Age, the Second Age, and then the two components of the Third Age that I really would like to talk about. Which is ES modules and the death of IE11, as well as polyglot tooling and collapsing layers of tooling. And then the death of JavaScript. Potentially what comes after the Third Age of JavaScript. Because the story doesn't end there. But maybe it transitions into a different story.

So the First Age of JavaScript, 1997 to 2007. For those who want to know more about the origins of the JavaScript, you should actually hear it straight from the horse's mouth from Ben and Ike. He gave this really great talk at .conf on a brief history of JavaScript. And the real insight here is that JavaScript was based on a lie. Netscape actually attracted him to build JavaScript by telling him that he could build Scheme in the browser. And when he arrived, they told him, no, you have to build a Java-like clone that isn't Java at all. It's a very interesting period in JavaScript's history, which is a very formative period as well. There was this hot period of formalization. I mark the start of JavaScript in 1987. It went back a few years before that. And there was a long period of silence where there was a civil war where we didn't really agree on the direction of ECMAScript 3.1 or ECMAScript 4.

2. JavaScript Community and the Oslo Meeting

Short description:

The community dealt with JavaScript by building compiled-to-JS dialects or modifying JavaScript itself. In 2008, a pivotal year, the Oslo meeting resolved the dispute between ECMAScript 3.1 and ECMAScript 4, leading to the roadmap towards harmony with ECMAScript 5. For more details, check out the manuscript of JavaScript, the first 20 years, by Brendan and Alan Worsbach.

Essentially, the way that the community started dealing with it was to have two tracks. One was they started building compiled-to-JS dialects of JavaScript, so there was some straight-up forks like ActionScript, Qt, JScript, or WMLscript. These are not compatible with JavaScript at all. Or you could stay within the bounds of JavaScript and just modify the heck out of it. So you can have jQuery, Dojo, and Mootools. Obviously jQuery did end up winning in the end. But I think 2008 was still a pivotal year, despite it not being a grey zone in terms of the way that I view my time chronology. I really like this idea of the Oslo meeting where everyone who was prominent in JavaScript at that time got together in Norway and resolved this dispute or this schism between ECMAScript 3.1 and ECMAScript 4. And had some kind of roadmap towards harmony, which is ECMAScript 5. So they said, instead of this evolutionary approach of 3.1 or a revolutionary approach of 4, let's take the best of each world and just come to some kind of concession so that browsers can start making a step ahead again. If you want more details on this, you should check out the manuscript of JavaScript, the first 20 years, which is kind of a book slash talk that was submitted for proceedings of ECM on Programming Languages that was supposed to happen last year. And it's 200 pages, so no one's read it. I've only skimmed it a little bit, but this is the story of JavaScript from the authoritative authors, Brendan, who made JavaScript, and Alan Worsbach, who was the editor for ES5 and ES6.

3. The Second Age of JavaScript

Short description:

The second age of JavaScript is about the community and ecosystem. In 2009, ECMAScript 5 and the dominant module syntax in Node.js and the browser were introduced. Different sections of the community emerged, including runtime and the emergence of build tools. Significant innovations like Closure Compiler, CoffeeScript, Grunt, Webpack, Typescript, Galp, Tracer, Rollout, Babel, and newer versions of Bundlers came out. Frameworks like Angular, Backbone, Meteor, ReactiveView, and Its Vault also emerged. This history spans over 10 years of runtimes, build tools, frameworks, and a shift left in JavaScript tooling.

OK. Then we'll talk about the second age of JavaScript. So if the first age of JavaScript was about forming the language, the second age of JavaScript is about the community, the ecosystem. In 2009, all these things happened in the same year. We reach ECMAScript 5, the Harmony specification, but then we also had this weird, like, common JS syntax that was proposed. That became the eventual dominant module syntax in Node.js and in the browser. Node.js was launched in 2009, and as well as MPM was launched in 2009. All these things we take for granted today were invented in the same year.

There are different sections of the community. So I'm going to break out a few of them. The first was runtime. You can track the gradual evolution of being able to run JS everywhere. You can run JS in a browser. Chrome also started in 2009, which is wild to think it's that Electron, you can run it in the desktop, you can run it on phones, and then you can have specialized runtimes just for Android. And that's a really interesting, low-level engineering thing that's going on. Obviously, there's probably other runtimes that I don't even know about, so let me know in the comments if there are that you think I should touch on.

The second part of the ecosystem I want to touch on is the emergence of build tools, the way to help you compile, and build, and bundle your JavaScript. So, Closure Compiler and CoffeeScript both emerged in 2009, as well. Very, very significant year for innovation. There was Grunt, Webpack, and Typescript around about the same time in 2012-ish, 2011. Galp and Tracer came out in 2014, and Rollout and Babel replaced Tracer, as well as the newer versions of Bundlers, Rollout, Parcel, and Bazel came out in the subsequent three years.

Frameworks also came out. So, we had, before Angular and Backbone, we had a bunch of others. But let's just call it the start of the second-age of JavaScript with Angular and Backbone. Meteor came out and tried to be full stack, with its own UI layer called Blaze. ReactiveView came out in 2013 and 2014. Its Vault came out in 2017, but it was essentially reinvented in 2019. So, that's the history. It's over 10 years of runtimes and build tools and frameworks. And there's one more trend which I like to call out, which is this idea of a shift left in JavaScript tooling.

4. The Third Age of JavaScript

Short description:

I've done two separate talks on this. One on Svelte and the great space elevator, talking about the evolution towards compiler-only frameworks, as well as growing a metalanguage, the importance of developer experience and developer tools for frameworks. Now we come to the third age where we basically do an RF on legacy JavaScript. The two assumptions here that are going away is that commonJS is the build target for all of our tooling, which introduces a lot of bloat. We're going to move to ES modules. It's going to be assisted by the slow death of IE 11. The second thing that we talked about is JavaScript tooling. We now write most of it in TypeScript, but also increasingly in Rust and Go. As well as the collapsing layers of the different jobs of the tool. First we'll talk about the ES modules and the death of IE 11. There are still some nuances, but by and large, the ecosystem is moving over. There are limitations that people should be aware of, but there are also solutions like using a dev-only unbundler. The one hurdle with this is IE11, the elephant in the room.

I've done two separate talks on this. One on Svelte and the great space elevator, talking about the evolution towards compiler-only frameworks, as well as growing a metalanguage, the importance of developer experience and developer tools for frameworks. This was presented at React rally.

Now we come to the third age where we basically do an RF on legacy JavaScript. Some kind reader did a nice mock image of this. I never played this game, but I heard it's lots of fun. Essentially, the two assumptions here that are going away is that commonJS is the build target for all of our tooling, which introduces a lot of bloat. We're going to move to ES modules. It's going to be assisted by the slow death of IE 11. I'll give you updates on those trends.

The second thing that we talked about is JavaScript tooling. We now write most of it in TypeScript, but also increasingly in Rust and Go. As well as the collapsing layers of the different jobs of the tool. First we'll talk about the ES modules and the death of IE 11. For those who don't know, what is an ES module is really just the import and export syntax that you might be seeing in a lot of your code that you might not actually know is being compiled away by Webpack. Webpack is acting as a sort of interpreter into environments that don't actually have the import and export ES module native language. But now, both browsers and Node.js have essentially this capability unflagged. There are still some nuances like using MJS, the Michael Jackson script, if you want to specify that you're working in modules, and there are some kinks to work out there, but by and large, the ecosystem is moving over. If you want to read a really good primer on this, you should check out the MDN docs on ES modules, and I think the V8 team has a good document on ES modules according to them as well. So, there's some nuances here and there's some more development to be done, but it's coming along and it's looking really good.

So there are limitations that people should be aware of. For example, you can't really just build ES modules and ship them in production in any of significant size. Even the V8 team recommends that there's a bottleneck of a loading pipeline when you're loading 300 modules. And so, if you start building any significant kind of app, you probably don't want to do this, but it probably is fine for a website. So you can still use a dev-only unbundler like Snowpack or Vite or WMR. And I think that's also a really good solution. So that's that's something that you see refreshing a lot of the tooling in JavaScript now today. That you don't have to bundle for development, so your development refresh cycles can be a lot faster. It can be constant time refresh instead of having to rebuild the entire projects every single time you save. The one hurdle with this, of course, is IE11, the elephant in the room.

5. Adoption of ES Modules and the Death of IE11

Short description:

There's support across the board for the ES modules native spec, but not for IE11. The U.S. government could drop IE11 this year, which would be a catalyst for adoption. Many companies and ecosystems, such as Vue and Angular, have already agreed to drop IE11 support. The new Microsoft Edge's IE11 compatibility mode also aids adoption. Adoption of ES modules is increasing in both browsers and Node.js, driven by Sindra and a coordinated effort. The time for ES modules is now.

There's support across the board for the ES modules native spec, but not for IE11. Part of the adoption of IE11 is very contingent on the death of IE11. So, on the top left, this is a screenshot of analytics.gov.us. And the key number to watch is the percentage visits from Internet Explorer. The U.S. digital service has actually identified the 2% mark as the critical benchmark level where they support browsers. It used to be 3.6% in November 2020 when I first started writing about this thesis. It has now fallen to 2%. So, it's fallen steadily and we're probably at about the time, and I think that the U.S. government could drop IE11 this year. And I think that's a very big deal because that's a catalyst that if the U.S. government has dropped IE11, we can drop it now at work. Obviously a lot of other people in the ecosystem have gone ahead and agreed with that decision. So, the Vue ecosystem has agreed to drop IE11 support. Angular has agreed to drop IE11 support, as well as a bunch of other companies like Skillshare, Twitter, GoDaddy, WordPress, Drupal, Daily Of course, Microsoft itself. It also really helps by this setting in Edge, the new Microsoft Edge, where they have this IE11 compatibility mode. So, even if your app needs to be running IE11, you don't have to visit IE11, you don't have to use IE11 most of the time. And I think that's a really big catalyst for adoption as this gets rolled out across some of the larger enterprises that require all these IE11 apps and don't have the budget to rewrite all those things just to upgrade browsers. So, adoption is slowly happening for ES modules, both in the browser. So, here's a screenshot of some stats from browser adoption of ES modules. It tripled in 2020 and I think it's going to do very well in 2021 as well. As well as in Node.js because it's mostly driven by Sindra. He's going to transition all his libraries over to ES modules. If you want to use his stuff, you have to use ES modules inside of Node. I think it's happening in a coordinated fashion because everyone senses that the time is now. It's been a long, long time coming ever since the first idea of standardization was floated whenever this picture was taken with Addy Osmani. It's coming. It's really coming.

6. Change in Tooling and Polyglot Tooling

Short description:

The next part of the third age of JavaScript focuses on the change in tooling. JavaScript tools are now being optimized for hot paths and speed, rather than ease of contribution. Many developers have switched to TypeScript, which has seen strong adoption in the React ecosystem. Other languages like Rust are also being explored for further optimization. The idea of polyglot tooling is gaining traction, where the core functionality is written in a compiled language for better performance.

Okay. The next part of the third age of JavaScript is the change in tooling. Brandon Dale called it in 2018 saying that in less than five years, most popular JavaScript tooling will not be written in JavaScript. I think this has mostly come to pass but in different The two assumptions that are being cleared right now is that JavaScript tools should be written for JS developers by JS developers so they can contribute. The reality is that they do not. So, we should optimize for hot paths and speed rather than ease of contribution by people who don't actually end up contributing. And the other assumption is that of the Unix philosophy, each tool should do one thing well. So, let's talk about those in turn.

So, the first is that whether we should only write JavaScript. The easy answer is, well, most people have just opted into writing TypeScript. So, here's an example of how much of the React ecosystem has switched over to TypeScript. I've been monitoring it. So, React Router, Next.js, Yarn, Storybook, Apollo, Gatsby, have all switched to TypeScript. These are the results from the state of JavaScript surveys, and the adoption of TypeScript has been extremely strong. You can say that TypeScript is won at this point. But TypeScript is by design very JavaScript like. So, what about the other languages that we want to optimize even further? Here's ES Build's benchmark. It's a web pack competitor. And it's about 100 times faster than the next fastest alternative, according to their own benchmark. So, take it with a grain of salt. But it is somewhat faster, for sure. And that basically comes from having a compiled language at its core. That's a very interesting observation. Because you also see that in Rust. You see that being adopted in Denno, in Relay, and in Volta. These all have significant Rust percentages in their codebase. And I think what's happening is this idea that we should explore Polyglot tooling. So, we used to have this concept of pure tooling, where you would write the external API in JavaScript, and you write the core in JavaScript as well. But it doesn't make sense to write the core in JavaScript, because it's a hot path. It gets executed again and again.

7. Optimization and Complexity in JavaScript Tooling

Short description:

No matter how much optimization you can do, you can probably do better by compiling it to binaries. We're changing our concept of what exactly a tool, one tool for one job means. The definition of what the one job is changes over time. When you look at all these tools that we're so used to putting together, why are they all different tools? And why do they have different plugins? That's a little bit of what happens. Our first reaction for this was actually very simple. We just swept everything under the rug. That's continuing to happen. We're sweeping the complexity under more rugs. We're starting to build on top of React as a stable boundary rather than reinvent frameworks all the time.

No matter how much optimization you can do, you can probably do better by compiling it to binaries. Or you can also do stronger type checking so it's more stable core. So, whatever it is, you can switch over your core tool to a systems language and benefit from optimization there. But you still leave your external API in a scripting language like JavaScript. This is the pattern we're going to move towards for a lot of our core tooling.

We're going to have Go, Rust, or TypeScript if we have to, and a JavaScript exterior. This sounds like heresy to you. I think it's because we're changing our concept of what exactly a tool, one tool for one job means. So, this is a really good blog post that I found from Benedict Evans on platforms and bundling. When word processors came out, they actually had different functionality and different plugins for word counts, footnotes, and charts. These are all separate products from separate companies that you have to go out and buy for $50 to $100 each. Can you imagine buying a word processor today and not having word counts and not having footnotes? No. So, today it just comes all bundled. How many plugins and how many, you know, different little tooling do you want in a word counter? I think the definition of what the one job is changes over time and that's what we're seeing happening in JavaScript today.

So, when you look at all these tools that we're so used to putting together, why are they all different tools? And why do they have different plugins like why do I have ESLint Babel prettier type script instead of just having one set of ecosystem tooling that works well together and has single EST passes and all that optimization that can happen if you have a holistic view of what the job of JavaScript bundling is. So, that's a little bit of what happens. So, our first reaction for this was actually very simple. This is something I covered in a previous talk called creating create React app. Which is that we just swept everything under the rug. We would say, okay, setting up Webpack is too hard to make a React app, so let's sweep everything under single dependency and you would just install create React app. That's a magical improvement in developer experience. But we just swept that complexity under the rug. The moment we need to deviate from it, you had to eject and now you're left with all that complexity again and all that configuration. I think that's continuing to happen. This is my other thesis called React distros. We're continuing to do that. We're sweeping the complexity under more rugs. Create React app, next JS and Gatsby does that for routing. And Blitz.js and Redwood.js does that by including other custom components and state and data frameworks. But we're starting to build on top of React as a stable boundary rather than reinvent frameworks all the time.

8. Collapsing Tooling and the Third Age of JavaScript

Short description:

This is another blog post that I have. If you look at Rome's investor slide deck, you can see the exact same chart of, like, why all these different tools, let's combine them into one tool. And you can see this in demo as well, which tries to collapse that into the node.js layer, which I think is a super interesting approach. These two, I think it's no coincidence that these two are now venture capital funded.

For collapsing tooling. I think this pitch is actually really cool. This is another blog post that I have. If you look at Rome's investor slide deck, you can see the exact same chart of, like, why all these different tools, let's combine them into one tool. And you can see this in demo as well, which tries to collapse that into the node.js layer, which I think is a super interesting approach. These two, I think it's no coincidence that these two are now venture capital funded. And I think that's another interesting innovation as well. In the first and second age of JavaScript, it was very sort of independent, open source volunteer movement. But now in the third age of JavaScript, I think there is some sense that we need a sustainable business model for great open source to be built. And I think the money is there to it. So, if you want to start a third age of JS developer tool project, talk to me. I can put you in touch with everyone. And I would be interested in funding you myself.

9. The Death of JavaScript and the Future

Short description:

Finally, we'll talk about the death of JavaScript and what happens after the third age. According to Gary Bernhardt's joke talk, JavaScript's future may involve WebAssembly. While WebAssembly won't replace JavaScript entirely, it has its uses, especially for large apps like Figma. In conclusion, this short talk provides perspective on the past, present, and future of JavaScript. If you're interested in learning more about spotting trends and making technology bets, check out my book at LearnInPublic.org. Thank you for being here and enjoy the rest of the conference.

Okay. Finally, we'll talk a little bit about the death of JavaScript, because what happens after the third age of JavaScript. And I think the best source on this is actually a joke talk by Gary Bernhardt on the birth and death of Javascript. Which is an excellent exploration of what happens when Javascript gets what happens after Javascript, essentially. I think that's something that Brendan Knight started to talk about as well. I had this conversation with him about what the universal virtual machine could be. And he says it's probably WebAssembly. He has started instead of saying always better JavaScript, he's started saying always better JavaScript and WebAssembly. And you're starting to see that in some of the tools that we push out. But WebAssembly is also not magic pixie dust. I don't think it will completely do away with JavaScript forever, but it is very appropriate for some use cases, and I think it's worth exploring for large apps like Figma.

So that's the overall thesis, right? This is a very short talk. But hopefully it's given you some perspective on where we've been, what we're going through right now, and hopefully where we'll end up. So I love your comments and questions, I will be in the chat for this conference. If you want to learn more about how to spot trends and also bets on technologies for your career, you can check out my book at LearnInPublic.org. Thanks very much for having me and enjoy the rest of the conference.

So the first one is speaking. Standups meets us at conference with 36%. You can practice this just by applying to a conference like this, like JNation, React, conference, so yeah you can apply to conference. That's a good way to improve that skill. Self care and prioritization, very important too. Writing blogging documentation, designs and docs, that's one of the skills I want to improve. And negotiation is the last one with 12%. It seems that there's a lot of good negotiators watching this conference so that's really good. So yeah, the number one is speaking.

Now let's see some of the questions. One is by Brian Hawk. How do you master technical blog writing? I find it's hard to balance the high level versus the technical. What do you define as the tech blog post? Sean? Hi. That's a interesting question.

10. Mastering JavaScript and Code Composability

Short description:

I don't think you ever master it. Just do it a lot and try to be better than you were yesterday. And after a few years of doing it, you'll be really good. Another question from Stark Odinson. Is keeping your code smaller in terms of file size can decrease the loading times. How do you balance between keeping your code short and keeping it readable? I see. I love this question. So I think the React core team's answer of composability really resonates with me here. So, what's actually the conclusion of the death of JavaScript by Comoser? Ah, there is none. It's just an observation. I kind of view myself as a JavaScript journalist. And the goal of a journalist is to write the first draft of history. In the sense that when we look at our web dev careers, 20, 30 years down the road, when we're retired and we're sick of programming anymore, what are we going to say about the 2020s? You know, this 10-year period from 2020 to 2030. We can already see some hints of what's going on. And I think my role here is just to call out, I think there's some trends that are very interesting. And these are things that I would invest in personally.

I don't think you ever master it. Just do it a lot and try to be better than you were yesterday. And after a few years of doing it, you'll be really good. Why are you trying to be perfect or master it? Just do it better than you were before. That's a great answer. Practicing everything you get better and improving.

Another question from Stark Odinson. Is keeping your code smaller in terms of file size can decrease the loading times. How do you balance between keeping your code short and keeping it readable? I see. I love this question. So I think the React core team's answer of composability really resonates with me here. You should be able to break down your code into logical code blocks. If it's too long, you have too much going on in your head. You should be able to extract things into reusable functions. You don't need to reuse them. You can just take chunks of code out and separate them so you can extract them into a single function. You don't have to break that abstraction nicely until you need to look into the implementation detail. So, composability of code is my answer of keeping code short and readable. Yeah. That's a good answer. Composability. Now you know.

So, what's actually the conclusion of the death of JavaScript by Comoser? Ah, there is none. It's just an observation. I kind of view myself as a JavaScript journalist. And the goal of a journalist is to write the first draft of history. In the sense that when we look at our web dev careers, 20, 30 years down the road, when we're retired and we're sick of programming anymore, what are we going to say about the 2020s? You know, this 10-year period from 2020 to 2030. We can already see some hints of what's going on. And I think my role here is just to call out, I think there's some trends that are very interesting. And these are things that I would invest in personally.

QnA

Sharing Ideas and Receiving Feedback

Short description:

So I would just share them. And if you agree, then that's great. If you disagree, let me know and we can have a conversation about it. Leah asks, thank you. Very interesting. Where do you get feedback in the early stage of plugin? Where do you get? Oh, okay. You know, so Twitter is a big source of my feedback. Daniel Berg asks how can you improve explaining complicated technical ideas doing daily meetings or code reviews? Oh, wow. That's interesting. I don't really know if I have figured that out. Puru asks, how do you balance DX and UIs like tools like by providing great DX but by default the lack of optimization in production that Gatsby and Next can provide? But Next and Gatsby are by default is lower than Byte, and so the whole DX is deluded due to the lack of speed.

So I would just share them. And if you agree, then that's great. If you disagree, let me know and we can have a conversation about it. I'm not trying to push some conclusion onto you.

Leah asks, thank you. Very interesting. Where do you get feedback in the early stage of plugin? Where do you get? Oh, okay. You know, so Twitter is a big source of my feedback. You know, I prototype a lot of blog ideas on Twitter. And if I see some traction, then I flesh a tweet into a full blog post. But sometimes a lot of people have questions on like where to start if you don't have any followers, and this is called the cold start problem. I would say you can join blogging accountability groups. So together with my book, I have a community that where we support each other with our learning in public and our writing efforts. So you can join a community, like whether it's a paid community, or a fee community, just among your friends, to share feedback. The other thing I encourage people is to have this essay called pick up what they put down, which means if you want other people to care about what you write, then make sure you're writing about something that they care about. And one way to guarantee that they care about stuff is just look at something that they've just released. Like let's say the React core team yesterday just released their roadmap for React suspense. If you want to write something, they'll probably read it, and they'll probably give you feedback on it. So that's a way just to respond quickly to something that someone else wrote, and you have a much higher chance of feedback than if you just publish, you know, like some random document that nobody really was looking for or asking for.

Daniel Berg asks how can you improve explaining complicated technical ideas doing daily meetings or code reviews? Oh, wow. That's interesting. I don't really know if I have figured that out. I think the venue of a daily meeting or like a daily standup is not the right place to explain complicated ideas. I really like the Amazon way of having a one pager or a six pager to write down the full narrative of a concept, and before what we so I worked at Amazon, we would call this like a business review meeting, we would actually sit down and have like 10 minutes of just reading that write up and document so basically try to write it down instead of just coming up with it on on the off the cuff, you know because when you write it down when you write things down you really get to organize your thoughts.

Puru asks, how do you balance DX and UIs like tools like by providing great DX but by default the lack of optimization in production that Gatsby and Next can provide? But Next and Gatsby are by default is lower than Byte, and so the whole DX is deluded due to the lack of speed.

Explaining Complex Ideas and the Amazon Way

Short description:

I don't really know if I have figured that out. I think the venue of a daily meeting or like a daily standup is not the right place to explain complicated ideas. I really like the Amazon way of having a one pager or a six pager to write down the full narrative of a concept, and before what we so I worked at Amazon, we would call this like a business review meeting, we would actually sit down and have like 10 minutes of just reading that write up and document so basically try to write it down instead of just coming up with it on on the off the cuff, you know because when you write it down when you write things down you really get to organize your thoughts.

I don't really know if I have figured that out. I think the venue of a daily meeting or like a daily standup is not the right place to explain complicated ideas. I really like the Amazon way of having a one pager or a six pager to write down the full narrative of a concept, and before what we so I worked at Amazon, we would call this like a business review meeting, we would actually sit down and have like 10 minutes of just reading that write up and document so basically try to write it down instead of just coming up with it on on the off the cuff, you know because when you write it down when you write things down you really get to organize your thoughts.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
Making JavaScript on WebAssembly Fast
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
Webpack in 5 Years?
JSNation 2022JSNation 2022
26 min
Webpack in 5 Years?
Top Content
What can we learn from the last 10 years for the next 5 years? Is there a future for Webpack? What do we need to do now?
Towards a Standard Library for JavaScript Runtimes
Node Congress 2022Node Congress 2022
34 min
Towards a Standard Library for JavaScript Runtimes
Top Content
You can check the slides for James' talk here.

Workshops on related topic

Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Hussien Khayoon
Kahvi Patel
2 authors
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
Gleb Bahmutov
Gleb Bahmutov
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
0 to Auth in an Hour Using NodeJS SDK
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Asaf Shen
Asaf Shen
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
Build a powerful DataGrid in few hours with Ag Grid
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
WorkshopFree
Mike Ryan
Mike Ryan
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
JavaScript-based full-text search with Orama everywhere
Node Congress 2023Node Congress 2023
49 min
JavaScript-based full-text search with Orama everywhere
Workshop
Michele Riva
Michele Riva
In this workshop, we will see how to adopt Orama, a powerful full-text search engine written entirely in JavaScript, to make search available wherever JavaScript runs. We will learn when, how, and why deploying it on a serverless function could be a great idea, and when it would be better to keep it directly on the browser. Forget APIs, complex configurations, etc: Orama will make it easy to integrate search on projects of any scale.
Back to the basics
Node Congress 2022Node Congress 2022
128 min
Back to the basics
WorkshopFree
Guillermo Gutierrez Almazor
Guillermo Gutierrez Almazor
“You’ll never believe where objects come from in JavaScript.”
“These 10 languages are worse than JavaScript in asynchronous programming.”
Let’s explore some aspects of JavaScript that you might take for granted in the clickbaitest nodecongress.com workshop.
To attend this workshop you only need to be able to write and run NodeJS code on your computer. Both junior and senior developers are welcome.
Objects are from Mars, functions are from Venus
Let’s deep-dive into the ins and outs of objects and then zoom out to see modules from a different perspective. How many ways are there to create objects? Are they all that useful? When should you consider using them?
If you’re now thinking “who cares?“, then this workshop is probably for you.
Asynchronous JavaScript: the good? parts
Let’s have an honest conversation.
I mean… why, oh why, do we need to bear with all this BS? My guess is that it depends on perspective too. Let’s first assume a hard truth about it: it could be worse… then maybe we can start seeing the not-so-bad-even-great features of JavaScript regarding non-blocking programs.