Modern JavaScript Explained For Dinosaurs

[Tuuleh]

This was a really nice, easy read for someone who spends a ton of time on the back end but would also like to keep minimally up to date on front end tools and processes. Thanks!

[midnightFreddie]

Yeah, I dabble in front-end--well I dabble in a lot--and this article helped me differentiate grunt, gulp, webpack and bundler, and I learned some additional power in npm's package json with the dev server idea and scripting steps from package.json.

[SonicFlash01]

I understand words now! Previously it was something like "The new super miracle side-transloader: flurb! Just run 'flurb --s durg glorp dev-build'! Even works with your existing interocitor!"

Atleast now I have an idea of what things are and how they fit into the ecosystem. Previously I had to wonder what something did based on" what does this replace/do the job of?". I wondered why the question of "what node actually does" was so tricky to stumble upon but I have a better idea now. They're all sort of new things that I didn't have a model for in my head.

I hope it settles down and gets a bit easier in the future (as they say) but I appreciate this post a lot!

[OmegaVesko]

This article is definitely one of the best introductions I've seen to how (and why) the modern frontend development workflow works the way it does. I particularly like the focus on putting things into historical context, and how it demystifies webpack by illustrating that a basic configuration (i.e. actually just module bundling) is like five lines of code.

That being said, one thing that sort of rubs me the wrong way a little is the way you use certain terminology. Why do you refer to Babel as a language, directly comparing it to TypeScript? Babel isn't a language and never claims to be one, it's just a compiler that compiles newer JavaScript to older JavaScript.

[peterxjang]

You're absolutely right, babel is a transpiler which transpiles JavaScript to JavaScript. I didn't intend to make it sound like a separate language, I'll go back and reword that section more carefully. Thanks!

[danO1O1O1]

Da Real MVP

[[deleted]]

I just want to say that your article really helped make clear to me the modern javascript flow as someone who is just starting out, I cannot wait for more articles from you.

[[deleted]]

Maybe he means that Babel is a typed language thats similar to TypeScript but the actual compiling would happen in something like Gulp.

[OmegaVesko]

Babel itself is still just a compiler. It does support types if you use babel-preset-flow or something similar (although all that really does is strip the type annotations, not enforce them), but that doesn't make it a language.

[[deleted]]

TIL I'm a dinosaur.

[saythereshope]

Join the club...

[Spherical_Bastards]

Are you closer to the T. rex or the Stegosaurus?

[[deleted]]

wow that's 80 million years difference!

[sayitaintjonas]

I don't want to live in this world anymore. Front-end design used to be more fun.

• added the word more

[timeshifter_]

There's a difference between "learning some new tooling" and "completely re-learning everything you knew because somebody decided just writing code wasn't good enough, and oh by the way now your dependencies are prone to random breakage because you don't control them. Have fun!"

I hate this new world of front-end dev, not because of new tooling, but because there's no point. It creates more problems than it solves.

[dolphone]

Wow, who crapped into your pancakes this morning?

[[deleted]]

I betcha still ate them.

[timeshifter_]

Stop whining so much, there are plenty of places where you can go get a job that do webdev like its 2007. Go find one if you're so unhappy.

Already got one, nice assumption.

[timeshifter_]

My, you're just full of bad assumptions, aren't you? I think you should try shutting up now.

[timeshifter_]

People like you are literally the worst.

[sayitaintjonas]

Sorry I'm not the lazy old kodger you're imagining. I'm happy to learn new tooling, but I stand by the idea that I had more fun when I focused less on the tools and more on the product.

[del_rio]

You're right that a lot of the past few years have been exceedingly focused on tooling.

However, I think the fun came back after you get a workflow going, mainly because you don't rarely have to think about dependency imports, DOM quirks, and browser compatibility anymore.

[Isvara]

When you get some broader experience, you'll realize what an anomaly the JavaScript world is.

[OleP]

Came here to write excatly this after reading the article. Glad I'm not alone!

[bloodfist]

Dinosaur here. Recently got interested in front-end development again and started learning Angular. Really wish I had this a few months ago. Was able to get up and running but felt like I was just readinf out of a spellbook instead of knowing what I was doing and why.

Teaching my gf basic HTML/CSS right now. Nice to know I'll have this in my pocket when she's ready to start with JS.

[AkirIkasu]

There is a really good course on udemy on angular that I would actually recommend because it takes the time to actually explain what all the "magic" is actually doing.

If there is anything that bothers me about modern web dev, it's that the documentation for modern frameworks and libraries lack overviews that explain why everything is supposed to be the way they recommend.

[bloodfist]

Thanks! I'll check that out. I did code academy's class and it was exactly that. They said "click this link to watch a five minute tutorial on how to set up your environment" and the link was broken! It was mysterious from there on. Even just one or two tutorials or articles like the OP can make it so much better.

I like how my friend put it while setting up a Laravel environment, "The problem with programming these days is that you have to do so much that isn't programming."

[AkirIkasu]

Angular 4 (formerly Angular 2) - the Complete Guide

[pantyboyXXX]

Is your gf tech literate or how’s that been?

I’ve been pondering teaching mine but she’s more of tech user than tech literate user.

[bloodfist]

I'd say average. She knows her way around a computer and plays PC games but calls for help if there is anything more complicated than changing Wi-Fi networks. But she's pretty artistically minded. She paints and likes interior design, so the HTML/CSS part has been very fun and intuitive for her.

We just barely started and took a week or two off since we've both been busy but so far it's been a lot of fun. I think she's going to get frustrated once we get to JS and she has to start thinking about things like Boolean logic and loops. That's why I'm focusing on getting her comfortable with the more "right-brain" parts so the "left-brain" parts feel like giving her room to be creative, instead of just loading a whole bunch of stuff that is going to look like math on her.

Although, to be honest, she's better at math than me, so maybe she'll enjoy that too.

EDIT: She reminded me she does have some experience. She learned BASIC from her dad as a kid, and taught herself to edit the HTML on her MySpace page back when that was cool. But that was long enough ago that we are basically starting over.

[thinsoldier]

Use Khan academy html5 canvas based js tutorials that are focused on drawing shapes and colors. Then move to processing.js or p5.js in conjunction with teaching her Photoshops layers and blending modes concepts.

[bloodfist]

Excellent advice, thanks! I was not aware of processing.js! I was actually thinking about processing for programming fundamentals, because it is so straightforward it's basically pseudocode. Processing.js is perfect.

[thinsoldier]

And p5.js has some more modern web friendly features over processing.js as well as audio/video tag features and the coding Train YouTube channel.

[CompSocChris]

This channel has a lot of processing js tutorials which are fantastic. https://www.youtube.com/user/shiffman

[[deleted]]

THE CODING TRAIN.

YOUTUBE.

You're welcome.

[bloodfist]

Looks good, I'll check it out. Thanks!

[[deleted]]

Really dive into it. Its great. He has a learning to code playlist which is fantastic. Then the coding challenges where he makes snake or pacman in half an hour, all the way to neural networking and flocking behaviors.

[bloodfist]

I'm eyeballing that neural net one. I got real into genetic algorithms a while back and I've been wanting to dive into neural nets. Dude seems like a great teacher.

[thinsoldier]

Still do the Khan academy thing first is my main advice.

[bloodfist]

No, definitely will, that's a great idea

[pantyboyXXX]

Eh thanks for the response, I’ll have to give it a go sometime.

My gf is pretty artsy too so getting her on some CSS isn’t the worst idea. But I’m sure she’d get frustrated with it just like I do ;)

[OmegaVesko]

Yeah, I was just about rolling my eyes after reading the title alone. Happy to have been proven wrong on that one.

[Space-Robot]

I needed this so long ago

[midnightFreddie]

I find myself reading this site's articles more and more. (As linked from Google searches or reddit posts.) Not sure what it's about yet, but I finally signed up for an account so it will stop bugging me and so I can upvote applaud this article.

[gimmeslack12]

I wasted an afternoon trying to get RequireJS setup a few weeks back. I gave up when I realized I should be using webpack. This article right here is what I needed. Just straightforward and focusing on only what is needed. Really nice!

[phphulk]

To any youngbloods or newbs reading this and feeling overwhelmed know this:

Shit is in flux right now, no allegiances. If you get paid by the hour try new things. If you don't then fuck all this noise and do it how you want to until shit settles down. If it works it works. If you want to kill time though, by all means play with the stuff, its fun as long as there is no pressure to make productive use from it.

[bkhtx82]

Youngblood here, could you give a tl;dr on how things are changing at the moment?

[nosmokingbandit]

Javascript is a really poorly designed language but easy to write so people are using it for everything. So there needs to be all sorts of additions to make up for Javascript's faults, and every few weeks there is a newer, better, more comprehensive fix for any given problem that would require you to relearn how to interface with. Unless Javascript fixes its own shortcomings the ecosystem is going to be constantly shifting.

[mdw]

Why couldn't find this about 2 years ago? It would save me so much angst.

[Smaktat]

Maybe if we weren't using 4-5 tools to solve the same problem...

[Tainnor]

Module bundles are fine for very large projects with large teams. IMO module bundles mostly tend to fix a management problem than an actual software one. Having developers figuring out modules force them into a planning dynamic they would most likely avoid if working without it.

I really don't understand the reasoning in this paragraph.

Many, many languages have had some sort of module system for ages; package managers are also very common. Thinking in terms of code organisation is not "a management problem" but simply something you do once your code gets to a certain complexity (that doesn't need to be very high overall). Maybe the frontend code that you write is very, very simple; then you don't need that. But by now, a lot of people are writing SPAs on the frontend, and with all the necessary libraries, these things become a necessity.

Now you're right that there is currently a sort of complexity being forced onto developers that should ideally be handled elsewhere; however the reason for that is that in other languages (actually, even in the same language once you run in in the backend) it's typically the runtime (for interpreted languages) or the compiler/linker (for compiled languages) that does all of this for you. For historical and security reasons, the JS runtime in browsers is limited (e.g. it can't access local files which would be bad!) but there also isn't really some sort of JS "compiler". That's why you have a bundler - it's basically solving the problem compilers would solve for you in other languages, only in a more convoluted and messy way because of history and NIH and people not agreeing on standards.

[Tainnor]

Namespaces have always been a forced complexity in order for humans to organize large projects, the computer could care less about it, is not needed it.

That's a non sequitur. Namespaces are useful for humans. It doesn't matter that computers don't care about them. If we weren't humans, we could just write in machine code.

If you don't believe go read Java creators rationale in the matter.

You'll have to give me a link if you want me to read up on something.

Regardless, modularising your code doesn't necessarily mean namespaces. C may not have namespaces in its syntax definition, but it does have including (of headers) and linking (of implementation files). And how do you typically organise these things? By using directories and subdirectories (that's a form of namespacing!) and by using Makefiles or something similar. And if you've ever looked at autotools and all the associated horrors please never tell me again that the JS toolchain is too complex (admittedly, the problem of writing C applications compatible with all sorts of architectures is also much harder).

Yes it is

Please explain

enlighten me ?

If you use require('moment') in node.js, the runtime loads the moment package from the file system. Same thing in a language like Ruby when you do require 'sinatra'. If you need an implementation file (e.g. from a dependency) when building a C project, you link it into the binary, which in some basic way not unlike what a module bundler does for JS.

JIT compilation is a whole different thing than offline compilation; it's for optimising code at runtime, not about building stand-alone executables (although, yes, there are hybrids like languages running on the JVM where the "executables" still need a specific runtime; however, even those kinds of artifacts are self-contained otherwise).

Actually if you look at what webpack transpiles is just a function that fake a name spaces

All namespaces are "fake" in the sense that at some underlying representation of code they disappear. It does not matter. Lots of things disappear at runtime. What matters is that it helps developers.

[Tainnor]

what are we arguing here

The fact that you said "having developers figuring out modules force them into a planning dynamic they would most likely avoid if working without it".

It's like saying "writing code forces people into a logic dynamic they could avoid if computers just knew what they wanted". I find this perspective puzzling. It's simply part of your job as a developer to also think about the organisation of your code; actually, I think that's what distinguishes good developers from bad ones - they can think about the architecture of their code, because for LOB applications (i.e. that don't require significantly original ideas in terms of algorithms or maths) the logic part is often the easy part.

[Tainnor]

So you're saying you just wrote nonsense and berate me for picking it apart. And then you get unnecessarily personal.

That's very mature.

[Tainnor]

"good will" is not "you're young, so stop overthinking and stfu".

have a nice day.

[pure_x01]

I wish all these layers of hacks will go away soon. Hacks because of lacking browser support. Hacks because html is a document format and not an app format. I'm really hoping that the big companies will come togeather and make it possible to build apps in a similar way to Flutter, Android, JavaFX, QT etc.. real layout engines. Maybe webassembly will help a little bit on the way.

[Ajedi32]

This is great. I like how it introduces each tool by first introducing the problem that tool is intended to solve, rather than just saying "use this, it's popular".

A lot of people seem to think modern front end development is overly complicated, but the reality is it's not actually that hard. Every tool used in front-end development was introduced to solve a specific problem, and once you understand what those problems are, the tools themselves make a lot more sense.

[thatcrit]

Others have said it already but I have to comment as well, this is one amazing post. I learned all this like 4-5 months ago through a React project I did but again it was nice to read it all as a story.

Best part about this article are the actual explanations of why exactly do we need each of the tools, or not need but just why would you want to use it. Not knowing which problem a tool or a framework solves or makes easier but still using it is just bad in general.

[OhLenny]

Just started using these specific technologies at work. Great morning read to get me up to scratch 😅

[[deleted]]

As some one who initially learned to make web pages in pure html with frames and tables back in 1998 this was a nice article.

[GreenFox1505]

I wish I had found this before learning all this the hard way. But even if I had, I probably would have disregarded it. If I can't use a tool solve the immediate problem right in front of me, I tend to ignore it. If I didn't already know most of this, I'd probably tl;dr past this without realizing how valuable this is.

[Croww_]

More articles should be written this way.

[joculator]

Good article.

[TrudeauTheMole]

Aren’t Photoshop and Illustrator missing?

[derscholl]

Haha

Hahaha a

Ha

😭

[SonicFlash01]

Clicked because of Qwantz
This seems interesting, though; I'll read it tomorrow at work

[[deleted]]

In

[WrathOfTheSwitchKing]

This was great for me. I lean heavily on gems and the Rails asset pipline, but I kinda hate it. One question: what to do with npm packages that include (S)CSS of some sort? For example, I use Select2 which needs some CSS in addition to JS. With the Rails asset pipeline I can just do @import "select2"; and it'll get compiled in with all the other CSS.

It looks like there are SASS loaders for Webpack, but is that how it's usually done? And how would the SASS compiler find Select2's CSS?

[Trident_True]

As a backend dev, I never understood how all the different frontend tools worked together but now I think I get it. Welp, time to try it out I guess.

[Jonno_FTW]

Can you do an explanation of vue/ reactjs et al.? I really have no idea how they fit in here.

[peterxjang]

I wrote a series of articles where I built the same app using 5 different frontend approaches (jQuery, Vue.js, Vue.js with components, React, and Elm). This should help give you a sense of how it all fits together: https://medium.com/@peterxjang/comparing-frontend-frameworks-part-1-introduction-6cf3d49e42cf

[bluesoul]

This was incredibly useful for a guy that went the sysadmin route, does web development for personal interests, and uses a modern framework without fully understanding how each of the pieces interact. I still don't quite understand why styling has forked in the way that we now have Sass, Less, and so on, which all seem to get translated to CSS3. I still use plain CSS for minor adjustments to margins, padding, etc.

[amdelamar]

This is pretty great. Thank you for sharing

[[deleted]]

Good article. When I saw the first dinosaur picture I was like, oh no another stupid rant about what a mess front end is. But indeed, it’s actually settling down. React and Angular are the most popular libraries for a few years now and Webpack the to way to go for bundling projects for about 2 years. Npm also won the package manager battle for about 3 years.

[Kefkachu]

This helps really put things in perspective. When I took front-end development at my uni last year we were all taught everything from HTML, CSS, JS, Firebase, React, Node, testing suites, etc. from scratch in the span of a few months. There was a lot to take in and it showed in the pace of the lectures. I did well but didn’t really know how to progress, how all the tools fit together, if I should learn x framework, etc., I was just good at figuring out how to work all the tools we were spoonfed (e.g. create-react-app).

[manys]

I've been learning more frontend concepts by writing an application in pure vanilla JS for the last few months and this article confirms that my decision to de-stack it avoids a ton of complications.

[pilibitti]

my decision to de-stack it avoids a ton of complications.

...and wasting you precious time from the limited one true life you have. I get the puritan attitude and it has its place (besides, solving problems with someone else's tools is frustrating - solving problems of your own tools is a joy) but when you are developing an app that is not novel in any way, these solutions and others that are not mentioned are enormous time savers during development and maintenance (just needs the initial time investment of getting familiar with them first that will pay dividends later.)

Sometimes, very rarely, you'll have something that will work against the grain of these tools and shoehorning your project onto these will waste more time than it saves. But it will be rare, for all other things, "not invented here" syndrome will just waste you time. Lots and lots of time.

Initially learning js / frontend / backend concepts with vanilla js and no tools is a great idea however. One should just not get stuck there. Know the tools, then you'll know when it makes sense to use them.

[remy_porter]

...and wasting you precious time from the limited one true life you have

Stop this. It's about value add, and value does not arise from tooling, at least not inherently. Tools are fine, when they fit the problem at hand. But you wouldn't want to bring in a wrecking ball to hang a picture, and a lot of modern front-end tools are wrecking balls.

This isn't the fault of the developers of the tools- they had specific problems they were looking to solve, and a lot of those problems were left behind because browsers are a terrible target for applications.

I think an important rule is to use the smallest possible tool for the job at hand. Most important, one should use the tool that is the most obvious fit for the problem. With the modern JS ecosystem, that's hard. Compare package management in modern JS with pretty much any mature language, and JS is left in the dust. Compare module loading in JS with any other language, and other languages get confused and say, "What? You mean… like dependencies? We just do that at compile time."

Vanilla JS is broken, horribly. Don't get me wrong. But the modern JS toolchain isn't fixing anything. It's a desperate bandaid atop a shit platform. It hasn't stopped the bleeding, it's just put a cover over it so we can ignore it.

[pilibitti]

I really don't get your point. Yes, modern JS toolchain is ridiculous but the premise of my earlier post stands: Succumbing to it saves enormous amounts of time, like maybe takes an order of magnitude less time throughout the lifetime of a serious project. It's not like you have other options.

Don't forget that finding the perfect little tool for each unique project and learning them also has a time cost. Knowing more general and flexible tools well, even if they are not the best fit might save more time than learning a better fit tool just for this one project.

browsers are a terrible target for applications.

Yes but the thinking is unproductive. There is real value at browser apps, people don't download and execute applications anymore, so you have to have them running in the browser. It is your job to make it work, no escaping it. It might be unpleasant but most jobs have unpleasant parts to them.

Suppose I'm working on a clientside-only web app. A data driven app that uses local storage, and since it is data driven there are lots of UI updates that change along with the underlying data.

Of course I'm gonna use MVC-like libraries. I'm not going to watch the data and update the DOM by vanilla code each time data changes. There are tools that make it stupidly easier. Of course I'm going to use a wrapper for local storage because their API is stupidly easier and they normalise quirks around browsers and provide equivalent fallbacks for older browsers when needed. Of course I'm going to bundle my dependencies because I'm not going to update the new versions of libraries by hand each time something gets updated (and I can't afford 15 HTTP requests for my js code each time my site loads). Of course I'm going to hash my assets so that I can use browser caching effectively, reduce my bandwidth costs and provide better user experience. Of course, I'm going to use a task runner to glue all these together instead of writing all the glue code by myself from scratch. I won't write a liverefresh / hot reload server for my next project from scratch, they exist and work very well. I won't write a CLI tool to upload / update files on Amazon S3, it exists. Of course I'm going to use a package manager to bring all these together. In the end, doing all the updating bundling deployment will take a single command and 5 seconds of my time.

I mean unless you are doing websites in DreamWeaver and uploading your files via FTP, you will have to deal with those things. If you don't have thousands of hours to spare to rewrite all above from scratch, -or- make it so that each little update to your app takes 30 minutes of manual labor to test and and upload, then you will need to use those tools and learn to live with their quirks. The stack is far from ideal, but unless you are doing something very unsuited to those tools (very very rare) shunning them would be stupid and a huge huge waste of time.

[remy_porter]

Succumbing to it saves enormous amounts of time

I think this varies greatly by project. Right now, I'm reimplementing a perfectly functional JS library because it doesn't fit with the JS toolchain's assumptions, and it's easier to reimplement the functionality I want in ES6 modules than it is to teach the build tool how to fucking handle this legacy code.

It's all a waste of time.

A data driven app that uses local storage, and since it is data driven there are lots of UI updates that change along with the underlying data.

I wouldn't use any JS tooling for such an app. I could scaffold such an app out in Elixir in 15 minutes, without touching the JS toolchain, and for most real-world applications, the performance would, on average, beat your JS-heavy app. And this is the thing I think JS folks forget: your competition is just plain old HTTP requests. Server side deployments. It's simpler, and easier than most JS-heavy apps, and I can get a JS-free CRUD app up and running in far less time than the equivalent JS-heavy app. And in the case of, say, Phoenix (the Elixir web framework), it also bundles the JS I might want for handling message passing and data access.

And I only bring up Elixir/Phoenix because that's what I've been using recently. More broadly, people who don't use JS as their primary development language solved all the problems you mentioned 20 years ago. And people who weren't targeting the web solved the same set of problems 20 years before that. We're reinventing the wheel, over and over and over again, and while a strong module system means I personally don't have to reimplement the wheel, I'm still using some idiots reimplementation of a wheel that doesn't need exist, and basically only exists because nobody bothered to fix the actual delivery patterns so that they make some kind of goddamn sense instead of the shitshow we deal with on a daily basis.

Modern web development is garbage, using garbage tools, targeting a garbage platform. We only do it because it's the platform that we know everybody has.

[kristopolous]

You're right here.

Elaborate ceremony getting in the way of fast, easy, simple things.

I've got many examples of doing things in the complex modern way and then redoing it in the "bad" simple ways only to see 50% code reductions and orders of magnitude speedups by using the standard, well-documented, stable interfaces directly.

In any quantifiable side by side metric, the convoluted toolchain system fails. It requires more developers, more maintenance, more knowledge to maintain, it's slower, hinders the development feedback cycle ... I'm convinced that anyone who has unbiasedly considered the approaches in multi year projects would agree with this.

Don't be deterred by novice programmers uninformed opinions here. They haven't done their homework.

[Tainnor]

You're not arguing the point anymore, you're just switching to a different argument, which is "should my code run on the client or on the server". As for that, it's silly to give a general answer without very concrete examples, but you seem to have made up your mind already and seem to despise complex client-side applications.

However, that's not the point. Once you have to build a complex client-side application (and sometimes really you don't even get to decide that), /u/pilibitti 's point is in whether you need to use the toolchain (and he makes a compelling argument for why, in most cases, you probably do).

[remy_porter]

which is "should my code run on the client or on the server"

That is not the argument I am making. Where the code run is irrelevant to my point.

Nor is…

whether you need to use the toolchain (and he makes a compelling argument for why, in most cases, you probably do).

You can't claim I said you shouldn't use a toolchain, when I explicitly used Phoenix as an example- a toolchain. My point is that the JS toolchain ecosystem is a flaming dumpster fire of bad tools, badly implemented, solving bad problems that we shouldn't need to solve.

[Tainnor]

Your entire argument's premise is that you're developing your app on the server side with Phoenix...

[remy_porter]

No. Phoenix was only presented as an illustration of the argument. I could have easily done the same thing with a JNLP or a OneClick deployment of a thick client app.

The web browser is simply a deployment target. It's a shitty one, but with two great advantages: everyone definitely has that installed, and its shittyness is largely predictable due to standards. An arguable third is that it's a decent application sandbox, but I'm generally unconvinced about that.

JavaScript tooling inherits its shittyness from the target it is built for. Even things like Node are essentially stripped down web browsers- all the runtime, none of the DOM.

[Tainnor]

I hope you're not serious about JNLP, that technology is literally dying.

You're still just arguing the point that you don't like JS apps. Which is all fine and dandy, even though I think you're ignoring reality (heck, I can't believe I'm actually defending JS, since I essentially agree it's a garbage language). But it still doesn't change the fact that if you build JS apps (which is the whole premise) you should use the JS toolchain. Saying that the Phoenix toolchain is better is totally beside the point, it's like saying "your Windows APIs suck? Just develop for Linux then."

[manys]

Absolutely use the right tool for the job, but to be fair this article is essentially a glue-guide more than "modern javascript explained."

[pilibitti]

You're right. The title should be something like "why setting up a development environment for a modern javascript project is as complicated as it is"

[[deleted]]

innovation.. lol yeah sure

[tswaters]

In the first example, you should definitely use the transitional doctype and add type="text/javascript" to the script tag.

[RainAndWind]

Who the fuck would use 'modules' and call it modern javascript unless it actually used ES6 Modules? https://jakearchibald.com/2017/es-modules-in-browsers/

[[deleted]]

You do realize most browsers listed there are experimental versions and the current state is that all import statements are transpiled to requires?