The Third Age of JavaScript | Hacker News Reader

The Third Age of JavaScript

swyx.io

77 pointsswyx85 comments

Current front end dev, here. My employer pays me to write JS, have been doing it for +4 years.

I've become comfortable with the fact that JS never stops changing (note the use of the word changing, not improving). I concern myself with fundamentals, not framework-flavor-of-the-month. I encourage others to focus on the same.

What I am not comfortable with is the stubbornly-held strong opinions many JS devs have. Much of the time, a particular JS dev will believe their way is the one-true-way(tm) (which is a problem among a lot technologists in general).

JS devs are the JS fatigue...not JS itself. I get bent when JS devs judge me for not staying up to date - JS is my 9 to 5, not my life.

For all the JS devs out there who hate me right now - check out Elixir, its the new "new."

FWIW, my personal projects are Spring Boot and Kotlin.

> stubbornly-held strong opinions many JS devs have ... a problem among a lot technologists in general

Hmmmm... well, I might agree, but that would depend on the opinion. There was a time when all programming was done using GOTO as the sole flow-control mechanism until a guy with a stubbornly-held strong opinion named Djikstra taught us that GOTO was considered harmful. Yet it's also the most natural way to code: a lot of people argued with him (in fact, the reason beginners don't use GOTO any more is just because it's not there, not because they've gotten more sophisticated). It's also a stubbornly-held strong opinion among many, but too few, developers, that global variables are also harmful. Unfortunately they're also the simplest, most obvious way to code, so a lot of developers default to using them.

If a developer has a stubbornly-held strong opinion, I usually give them the benefit of the doubt to try to figure out why: often they have a good reason. (On the other hand, sometimes the reason is, "it's easiest", like using public static variables in Java).

The GOTO topic is an interesting one because Dijkstra inadvertently started a cult around the avoidance of GOTO. Dijkstra never intended this and one of the main reasons this occurred was because Dijkstra's original paper "A Case Against the Goto Statement" was editorialised as a letter to the author type article to speed up publication which resulted in the famous title "Goto Statement Considered Harmful".

This is a topic where both him and other prominent figures such as Donald Knuth have since its publication repeatedly argued for moderation in use of the GOTO statement and against the total avoidance of GOTOs.

My go to example for this is that in C and other languages that lack modern comforts such as exceptions(for better or worse) and destructors, GOTOs can largely simplify the handling of clean-up and error recovery code.

Another example is longjmp which is very useful in kernel-space or bare metal programming, and in implementation details for exception handling however outside of those niches, serves no purpose.

GOTO serves a very useful niche but can also make code nigh impossible to follow. Most other structured programming statements have the same threat but we have rules in place to avoid their abuse. The following cases can result in code that is just as problematic:

IF/ELSEIF/ELSE: overly large, overly nested, or mutating variables.

SWITCH/CASE: complicated fall-through.

FOR: mutating counter variables, mutating termination condition.

TRY/CATCH/FINALLY/THROW: exception hell/deep uncaught exceptions.

These control flow mechanisms should definitely be preferred to GOTO in most cases but they can be just as badly abused if you aren't careful. The big difference I find is that people are taught how not to abuse these mechanisms but most material about the proper uses of GOTO is almost taboo because of the cargo cult around avoiding its use.

Sorry if this doesn't really fit into the discussion but it's interesting to me how an initially very tame and rational counter-argument spawned a massive cargo cult.

> but they can be just as badly abused if you aren't careful

No, they can't. Old-school goto can create entire new problems in a codebase, that aren't possible to replicate with the structured constructs. That's the entire point of structured programming.

Of course, it's possible to use goto well. But eliminating it eliminates the problem.

Agreed. Well-reasoned stubborn opinions that are fleshed out through critical thinking are examples of good opinions.

The stubborn opinions from fads, not so much. Those opinions try to signal - 'I am the smartest because I know the latest and greatest.'

Any good reading suggestions regarding the idea that global variables are harmful?

Yes. The largest global-heavy, non-public, codebase you have access to.

Reading a treatise on globals if you don't already have the taste to suss out much of the cost/benefit of globals on your own is a recipe for taking the contents out of context and treating the recommendations too broadly/narrowly.

> treating the recommendations too broadly/narrowly

That's a good point - mis-applying best practices because you don't really understand them is almost as bad as just ignoring them to begin with.

> I concern myself with fundamentals, not framework-flavor-of-the-month.

The whole framework-of-the-month thing is a meme. The overwhelming majority of companies use Angular, React or (to a lesser extent, Vue). There hasn't been a serious new framework in years, except maybe Svelte, which hasn't really caught on.

> What I am not comfortable with is the stubbornly-held strong opinions many JS devs have. Much of the time, a particular JS dev will believe their way is the one-true-way(tm) (which is a problem among a lot technologists in general).

so...not actually a problem with JavaScript if it's a problem among "technologists in general"

> I get bent when JS devs judge me for not staying up to date - JS is my 9 to 5, not my life.

I'm a professional JS dev too. I don't study it on my own time, but reserve a portion of my work time for keeping up to date with language changes. Maybe nobody is paying you to do that explicitly, but having a modern JS vocabulary could mean the difference between getting the next job or not, or how much you get paid.

when I got hired at my current job it took me 2 days to start being productive because they were writing modern React and I was used to the current paradigms.

I'm so tired of devs online ranting about how the problem with JS is that everybody expects them to keep learning new things. Do what you want, but keep that "JS devs are the problem" stuff to yourself. Maybe you'd be happier writing BASIC with GOTOs

> (note the use of the word changing, not improving)

I find it interesting that you say that. Has JavaScript changed for the worse? That's not how I've seen it, since a lot of problems like the lack of real modules, no async/await, lack of syntactic sugar for "classes", no `for (const x of y)`, weird variable scoping, no constants, bound functions(i.e. fat arrow functions), have been solved. I can't see how JS has gotten worse.

Some parts of the community are worse, perhaps. It's been years since React has been released, and people still seem to believe that React should be used for anything and is the only tool for any "serious" web development.(I'm not ragging on React itself, but the people who treat it like the new jQuery) Overall, JS devs are still trying to out-innovate each other by monkey-branching paradigms, which I think is the real churn with JS.

I guess that's related to your final statement. The perceived churn of JS to me is self imposed to some extent. I've been doing Ember development exclusively for the last 4 years and haven't had a problem finding employment or contract work. If I can make a living working with what people consider a "dead" framework, then that's a sign that you don't need to chase the latest and greatest JS fad.

> That's not how I've seen it, since a lot of problems [...] have been solved

"Solved" is an overstatement. The javascript ecosystem is house of cards. Modularity is far from solved, for example support for the browser field in package.json is all over the place, hoisting leading to phantom dependency bugs is another clusterfuck. A large number of popular packages want to own module resolution or parsing or both (jest, typescript, CRA, storybook, yarn v2, to name just a few), leading to inconsistencies between tools. Not too long, create-react-app broke because of some oversight from some library author over some package.json field lead to a broken publish. Bizarre bugs from the tree-shaking vs side effects dichotomy. The existence of things like yarn resolutions and patch-package and proxyquire. Abysmal symlink support. The list just goes on and on.

You _can_ get little pockets of very tightly integrated experience w/ comprehensive toolsets like Angular, Ember or to some extent CRA, but if you need to venture outside in a non-trivial way, the pain of fragmentation is real.

Those are mostly problems with Node.js, not JavaScript itself. But fair point since they are part of the JavaScript ecosystem and I did mention a framework. The different module implementations are a problem, but at least there's a standard that they are mostly emulating now and native support will eventually work and be adopted, especially with HTTP2+.

"Solved" might be an overstatement, but there's still been a ton of improvement. ES5 is a madhouse compared to what we have now.

FWIW, many people have the opinion that classes were a bad design. (I’m of the opinion that closures and anonymous objects do everything you’d need from a class, but better.)

The other language improvements are definitely unanimous wins though.

> Has JavaScript changed for the worse?

Clarification - I don't think JS has changed for the worse, but I do not think it is clear that all the changes have been for the better, both for the language and the ecosystem.

I see it as a double edged sword.

Take the example of handling asynchronous operations - async/await is good solution for that. But now you will be working in code bases with callbacks, promises, async/await, and possibly even generators - with generators being an example of an area that was not a clear improvement in the right direction, but an experiment now obsolete because of async/await.

I'm a fan of improvement, but nowadays I try not to pick up the latest trend for concern that it might be obsolete in the near future. You demonstrate this - you picked something you like (ember) and just stuck with it. Ember solves problems, it works, no reason to refactor your ember projects to react.

Quite the contrary: Generators are quite useful in their own right, independently of asynchronicity.

Maybe I have been in a corporate bubble, but I haven't seen much churn in the past couple of years. React is everywhere, with a smattering of Vue and Angular here and there.

I have seen a lot of churn react-land alone:

* instantiating with React.createClass(), then es6 class components, with functional components and higher-order components, now react hooks

* state management, with flux, then redux and mobx, and now context API

* bundling with webpack or rollup

* types with flow and typescript

I could go on. I am sure there's more I am not even aware of.

Yeah, but swapping out redux for `useReducer` doesn't require you to relearn the core concepts of React. The move from `React.createClass` to `es6` was clearly driven by the JS standards themselves evolving. At any rate, you're not having to rearchitect your whole React app for any of these changes. If you're still using Redux, that's cool, it's not necessary for you to swap it out and state management was never prescribed by React in the first place.

Though it isn't specific to React, I'd say going from REST to GraphQL is a pretty large change that's been trending these past few years.

In React land, I think the churn is mostly around what's considered idiomatic. At some point there were mixins, props-down-events-up, HOCs, old Context, new Context, render props, hooks... On the semantics side, first we started w/ "just recomputing the vdom is faster than poking the DOM a million times", then shouldComponentUpdate and object identity, React.memo, libraries automagically wiring stuff to work around the "just recompute the whole vdom" paradigm.

I wouldn't exactly say it's been a stable foundation.

A lot of those old paradigms you've mentioned have just evolved into new forms, based on lessons learned. Moving from mixins to HOCs, for example, should be relatively easy because they're based on the same concepts [1] and are solving the same types of problems.

Another example: React.memo does not replace shouldComponentUpdate, nor is it more idiomatic. React.memo is for /function components/, while shouldComponentUpdate is for class components [2].

Another example: the community wanted a more flexible way of using function components with state, and a way to decouple unrelated state: enter hooks. They're not necessarily more idiomatic, but instead provide an alternate way of structuring components and application logic that fits more use-cases.

New context is the same as old context. Hooks just enable another way of interacting with context.

[1] https://medium.com/@dan_abramov/mixins-are-dead-long-live-hi...

[2] https://reactjs.org/blog/2018/10/23/react-v-16-6.html#reactm...

> have just evolved into new forms, based on lessons learned

Well, yeah, that's what churn means. Consider, for example, that Vue and Angular have more or less stayed the same in terms of how people are supposed to write idiomatic code. The vue equivalent of hooks is very much seen as yet another option on equal footing (if not slightly derided as bandwagoning) since the old ways are just as expressive. When I hear people talking about React hooks, it's certainly not framed in terms of "oh it's just a different way of writing the same thing", but rather "oh it's better because it solves a bunch of issues w/ older idioms".

Another example, Mithril.js adopted element-level lifecycle methods (similar to Inferno et al) and the community largely thinks hooks are unnecessary - the last major bump was only major due to obscure semantic technicalities rather than introducing major ways of writing code (Vue is another great example that similar in this regard as well)

Yeah JS and the ecosystem changed far more from 2010-2015 than in the last 5 years.

Some changes in JS interpreters can be invisible. I recently noticed that an algo (that had worked for ~ 8 years in multiple browsers) had stopped working (for how long? in which browsers?) It (non-rigorously) distinguished 'string integers' from 'string non-integers'.

No doubt the required tightening was a benefit, but the breakage was not at all visible. Luckily it was a cosmetic (non-critical) usage.

As someone who has been working primarily with JS since the "First Age" of this article, I can say that from my perspective things have improved by orders of magnitude.

New language features are obvious improvements. The paradigm shift from imperative UI management like jQuery to declarative UI management like React has eliminated entire categories of concerns.

Almost everything you see mentioned in the "Second Age" might be easy to take for granted if you've recently arrived, but they have not always been there. While they are not perfect, to say things haven't improved is shortsighted. From the high-level view we are making major strides.

It's an iterative process, where some things win out, new ideas and "flavors of the month" gain footing or wither and die. jQuery for example had competition from mootools, prototype.js, and others, but jQuery established dominance for a variety of reasons. It won mind-share by being the best implementation to solve a class of problems the community was tackling at the time.

> What I am not comfortable with is the stubbornly-held strong opinions many JS devs have.

Meanwhile having your own stubbornly held strong opinions.

Guilty on strong opinions, but loosely held.

Example - at one point in my career, I wanted to Node all the backends and hated Java. Now I like Java. I am also starting to dig Elixir. I'm sure that will change again.

There's still a lot of magic floating around in code bases. I still see window passed into functions in the name of efficiency. You'll still see all sorts of varied opinions on html/css efficiency. It's certainly gotten better as large frameworks have stripped out the magic code, but you can find it when you update a site that was built a few years ago.

Let me guess... doing code reviews sucks?

I didn't mention code reviews, nor do code reviews have anything to do with JS.

Something that bothers me about working on node is that there is no consensus for basic stuff. Too much time on new projects is spent on reinventing the wheel and getting the team to agree to a standard.

2020 feels like a new age because of the browser ecosystem. The actual endpoint of the "second age" is probably the combined forces of:

1) Windows 7 Support officially ended

2) Edge now switched over to Chromium

With the exception of highly niche applications and markets, sites meant to be consumed on computers can aim for Chromium support and developers can rest assured they are covering the overwhelming majority of the market. Many slower-moving enterprises are standardizing on Chromium-powered browsers. Even NetFront (browsers used by video game consoles) is switching over to Chromium

The "Third Age of JavaScript" isn't marked by tooling or frameworks or code structure, but rather by developers able to focus on one browser instead of multiple. This new age will be marked by innovative use of APIs that people disregarded in the past because they only worked in Chrome.

> developers able to focus on one browser instead of multiple. This new age will be marked by innovative use of APIs that people disregarded in the past because they only worked in Chrome.

Ah, just like the good old days of `new ActiveXObject("Microsoft.XMLHTTP");` ;)

I see the opposite. I've talked to a lot of developers who have move to Firefox out of concern for things Google has been doing with Chrome recently. Though, developers are a minority for sure. Most people don't follow tech news closely enough to understand why they should be concerned.

The only place I can really see this making a difference is webassembly (which is not JavaScript). People have been transpiling their code to erase js discrepancies for years.

I doubt it, iOS is still a thing and will drag down support for new browser features.

The Third Era would've been far more dramatic sounding, especially when spoken by Patrick Stewart.[0]

Sorry, I couldn't help but draw an Elder Scrolls comparison here:

"Behold, in darkness, a doom sweeps the land."

"I have seen the gates of Oblivion, beyond which no waking eye may see."

"These are the closing days of the Third Era, and the final hours of my life."

Each statement could just as well have been spoken by your typical late 30s web developer that's seen some shit. That's lived through innumerable instances of framework and toolchain hell. That's probably being pushed into management because they're almost 40.

[0] https://www.youtube.com/watch?v=JGhlg4JqvQw#t=0m44s

"And Gandalf said: 'This is your realm, and the heart of the greater realm that shall be. The Third Age of the world is ended, and the new age is begun; and it is your task to order its beginning and to preserve what must be preserved.'"

I stand corrected! Equally dramatic-sounding. :)

Ironic that Gandalf was of course played by Ian McKellen in the films, and is good friends with Patrick Stewart.

I was surprised there was only a mention of frameworks.

One obvious shift I’ve seen is in the use of the WASM and Web GL compiled applications. The likes of Figma and Superhuman are making incredible leaps in user performance.

I suspect serious companies will make strides here.

Yeah, JavaScript's Third Age will be ceding the browser to better languages due to WASM, no?

That's super interesting, never heard that about Figma. Is the entirety of Figma in WASM or just the core drawing engine?

Design document are stored, manipulated, and rendered in WASM and WebGL. The surrounding UI (toolbar, properties panel, layers panel, etc) is written in React.

It's done that way because documents can get really large and having more low-level memory management helps a lot there. On the other hand, writing UI in C++ is really tedious and React has served us great. For non-performance sensitive areas, I'd much rather use TypeScript + React, despite being comfortable writing C++.

So obviously we're big fans on WASM, but we don't expect nor want JS/HTML/CSS to go away anytime soon.

Looks to be the entire app: https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

author here! i left that one specifically out bc a) i dont really know much about it and b) thats not technically JS (btw i think superhuman uses coffeescript not wasm/webgl). i am focusing on js here.

but all entitled to their opinions, js could die in 10 years for all we know

Meanwhile, jQuery is still used on 74% of all websites [1] despite being part of the 'first wave' obsoleted in 2009. If all this Javascript evolution is failing to gain traction across the whole of the web, is it really transformative, or is it just innovation for its' own sake?

[1] https://w3techs.com/technologies/details/js-jquery

React is not a replacement for jQuery. I've seen many codebases that are written in React, but still include jQuery for some legacy function in the app that references $.param or similar. Using this stat to say anything other than "jQuery is bundled on X% of sites" is pointless.

If you could determine which sites are built using jQuery as the primary "framework", that would be informative. But even then, jQuery is just a library of utility functions, comparing it to React/Angular/Vue is pointless.

There's lies, damn lies, and statistics. Are those websites the professional applications that people tend to rely on and have the biggest impact (i.e. Twitter, Facebook, Gmail, etc) or are many of those personal or legacy websites and web apps that happen to be floating out there? Websites and web apps are a spectrum of complexity. The more complex a web app gets, the more painful the reliance on an imperative library like JQuery becomes. Despite all this, even many apps that are primarily architected in Vue or React or whatever may lean on JQuery as a dependency for legacy browser support or polyfills.

3rd-Age: People will finally learn to effectively use vanilla JS, DOM API, HTML5, and CSS3 and will stop relying on transient abstraction tooling. They will actually learn the standards rather than rely on a Tech team's rendition of the next new thing.

Roast me

Roast you? How about this: a version of this comment is posted on just about every JavaScript post for the last five years and it hasn't changed much.

> a version of this comment is posted... for the last five years

Sounds like he is right and you are too old and averse to change to admit it!

Given that we've gone in the opposite direction towards greater abstraction from jQuery -> React/Angular/Vuejs and more tooling, doesn't seem likely.

I've* (not we've)

No, we've. If you're a professional JS developer in 2020 coding everything in vanilla JS with no framework or tooling, you are in the minority.

I'm just going to link this with no other context: https://www.youtube.com/watch?v=Yx6k6WR8GRs

Is this a debate one that's based upon what you think is actually happening, or what you hope is actually happening? I admit I don't have a perfect vision of the industry, but frameworks seem very popular.

I started off programming Windows 3.1 in C. So that argument just holds no attraction for me. As far as I'm concerned the browser is a bloated and extremely poor abstraction for building a UI (although it's a good document viewer). Any framework on top of it is peanuts in comparison.

Web Components are the future! /s

https://developer.mozilla.org/en-US/docs/Web/Web_Components

Yes! Component design and rendering state changes does not require Vue/React/Angular, wake up people!

I think this is spot-on, and I'm 100% here for it. Here's a secret: even JS developers don't like all the frameworks and build complexity. We like what they afford us, but the overhead has been a symptom of an immature ecosystem. I think most of us are glad to finally see the cruft starting to get shaken out as it matures.

My guess: WebAssembly and the birth of the polyglot web. C#, Rust or C will life and interact with HTML and JavaScript.

My prediction - the third age of Javascript will be the same as the second with tooling headaches, "transpiling", and fractured dialects. Except in this age we are all forced to use it as major companies sandbox away powerful APIs in favor of more control of their stores.

Dark times are ahead. The future is chrome. https://www.youtube.com/watch?v=_SCfNhyIo_U

> Dark times are ahead. The future is chrome.

Nothing strikes fear into my heart like this does.

Reminds me of that one Spongebob episode where everything was chrome.

I was thinking more Fury Road myself.

Definitely does feel like something new is in the air. I got into front-end (after a few years of back-end) during the rise of jQuery and CSS layout, remained super excited about it even with the problems through the backbone years, checked out in disgust and retreated to the back end after my first few Angular apps. Apparently missed whole sub-eras (have no idea what Prettier and Parcel are). Svelte and Deno are both pretty interesting, React at least seems stable and oriented around a smallish number of straightforward concepts, seems almost safe to come back into the water. Almost :)

Still wondering, though, if there aren't a lot of cases where a document-oriented approach (moving markup rather than JSON, progressive enhancement, good old standards) wouldn't serve an application domain better...

parcel is a bundler.

Prettier is an optional part of developing in JS that is hard to live without once you're used to it. instead of worrying about perfectly formatting your code, just write it and let prettier fix the formatting.

The third age of JS is going to be really exciting. People treat JS-land as something that has a first class language that can build major production tools and applications. Cloud providers support JS for nearly all aspects of their large platforms. The one place where I anecdotally see a decrease is in full-stack JS apps, but that's because the entire premise of a singular back-end app is under scrutiny by the cloud ecosystem itself. JS just never had a chance to get more established as a back-end language before that happened.

What? Node.js is as strong as ever. With Next.js it's never been easier to create a full-stack JS app. I don't see what any of this has to do with the cloud.

My comments were an observation based on what I've seen recently, and none were intended to be a value judgement on any work being done in JS-land. I just don't see a Rails-esque competitor rising from JS land anytime soon and gaining enterprise market share. Cloud has to do with it because Cloud is increasingly how applications are created. Instead of a large framework to create an application with a language (Spring for Java, Rails for Ruby, Django for Python), applications are now mishmashes of cloud functions, no sql tables, sql data stores, message queues and auth wrappers, all of those without a specific language requirement. Like I said in my original comment, it forces every language based framework to question it's (comparatively) monolithic nature. This isn't a fool proof prediction by any means, but with the rise of cloud architectures I really don't foresee any languages birthing a monolith anytime soon. I'm sure lots of folks will use Next.js or something else, and it will be good a tool, but my bet is that even more companies will increasingly utilize the cloud to create less monolithic architectures.

Ah it seems by cloud you were talking about serverless. I'd say that's still a significant minority.

I never used Rails, and it's true that Node.js doesn't have any single standard framework that everybody uses (maybe Express.js would be the closest?) But today there are definitely a hell of a lot more companies hiring for Node.js developers than Rails developers.

Rails-like for JS is coming via RedwoodJS and blitzJS. How much successful they will be? I have no clue.

AdonisJS and FeathersJS has been pretty successful.

> the Third Age is about clearing away legacy assumptions and collapsing layers of tooling.

i feel like the bit about "clearing away legacy assumptions" wasn't substantiated very well – basically just "CommonJS isn't necessary anymore because ES Modules are a thing now". which is true, but i feel like a sweeping statement like that needs a bit more. and if that assumption is where other "legacy assumptions" stem from, it'd be nice to expand on it a bit

My take is that we're never going to see ES Modules in the wild in web apps as we know them today, outside of some tutorials or open source apps. There's too strong business incentives to the contrary, legitimate or not.

Business incentives like supporting Internet Explorer for clients $$$?

Obfuscation. If web app companies could, they'd send your browser a binary instead of HTML and JS.

isn't minification good enough at obfuscating the code? what does CommonJS add here?

(that's a legit question – i've sifted through webpacked JS a few times, and it mostly just added a bunch of

  (function(module, require, ...) {
     <your module here>
  })(...)

around the code. tedious to read, but not much in the way obfuscation)

and i guess if ES Modules turned out to be more performant (bc the module stuff is handled by native browser code, or maybe some HTTP/2 magic with loading), that could be an incentive for adoption

I've combed through minified JS a number of times. Not enough if you want to prevent someone from going through your shit.

wasm will give them everything they want in that department.

Like vite and snowpack, I've been also working on a project which aims to provide fast development experience. Unlike vite and snowpack, it supports CommonJS too and it's somewhat more configurable. Dropping it here, just in case someone finds it useful - https://github.com/sarsamurmu/reboost

at yazz we have bet on javascript when many others are moving away. why? because javascript is here to stay as the defacto Browser language. Show me a Mainstream browser that plans to drop JavaScript support and we will Drop JavaScript too

I used to take this same perspective, but if you look at how you are coding javascript now, you're building and bundling, so though browsers may continue to run Javascript, that doesn't mean your code will always be written in Javascript.

We moved to Typescript two years ago, and now that I'm comfortable with that, and compiling to JS, I wouldn't be surprised to see good compilers for Rust or other languages become the standard in the future.

Good points. If typescript becomes the standard then for sure we would consider whether we should move our product to typescript

Typescript is becoming VERY popular. I Deno (the potential replacement for Nodejs) is written in typescript.

I hadn't worked with types before, and hated it when I first started, but once I got used to it, it's a nice experience.

maybe.

but also, there’s a classic pattern of articles which look back and describe a timeline of “past, present, future” where future starts tomorrow due to this thing I’m excited about today.

Reply on news.ycombinator.com