You Really Don't Need All that JavaScript, I Promise • Stuart Langridge • GOTO 2019

This presentation was recorded at GOTO Copenhagen 2019. #GOTOcon #GOTOcph

Stuart Langridge - Member of the Web Standards Project's DOM Scripting Task Force, Podcaster, Developer & Author @StuartLangridge

ABSTRACT
JavaScript is your behaviour layer; the way to add interactivity to your sites, to provide a slick and delightful user experience, to make everything fast and easy and clean. But at some point everything changed: the tail started to wag the dog instead and development became Javascript-first.
We'll talk about how you maybe shouldn't rely on JS as much as you're told to, and some practical strategies for how to build sites without reaching for a JS framework as first, last, and only tool for making the web [...]

Read the full abstract here:

#JavaScript #JS #HTML #Frontend

CHANNEL MEMBERSHIP BONUS
Join this channel to get early access to videos & other perks:

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[drissAithafid]

Here are all the mentioned twitter accounts, so u can follow them to stay updated:

Zach Leatherman : @zachleat
Alex Russell : @slightlylate
Ana Tudor : @anatudor
flaki : @slsoftworks

[JayJay-kimi]

Nobody will read this, but when you're developing landing pages, and promotional websites, the number one problem that has to be solved is "Does this work on every browser?" ... we're talking IE too folks. The other important problem to solve is "make this page and its data load as fast as possible". The only solutions I've found is code your JS by hand or use jQuery slim for complete cross-browser support (don't knock jQ in this arena). Test on multiple devices. BrowserStack helps, but real devices are better. Make use of data attributes to store state (like vue). Over time you'll repeat the same patterns, put your code into your own library. Your JS, and CSS, should be minified, and injected into the HTML. Ultimately you are trying to squeeze out conversions by not losing those with older devices, or on slower connections. Bottom line is money talks. I've been developing websites since 2001. We're coming full circle again. I could talk for days about this. I get my mic pre-amp soon so I can start doing videos again.

[burningdog]

Awesome - first time I've heard of the <portal> element.

[andrew]

He makes very fair points on our lack of knowledge of what modern html and css can do, but I honestly don't see why anyone would split their website with spa (react) and raw html. Less code is better. But less _architecture_ is FAR more important when scaling a product. Do you really want to split a single responsibility into two distinct entities in a codebase? How do you keep track of what exists in raw html and what exists in your spa? You would traverse two entire hierarchies based on an arbitrary set of rules as to what belongs where. Also, what happens if a new business requirement (which changes all the damn time) requires something only possible in an spa that currently exists in a colossal hierarchy of raw html? Do you inject a React app into the middle of that raw html? Are you asking for a maintainability nightmare? Do you refactor that code and incorporate it (somehow) into your spa? Have fun with that.

[xucongzhan]

It resonates with me when it comes to using more native web APIs to achieve things, and don't always "I am adding this lib because it helps to build this one component/functionality". If CSS animation suffices, why add another JS lib just for animation, right? But on the other hand, project architecture & maintainability is also critical.
Most of our old apps use jQuery and some designers love them for writing one-off scripts for one single interaction (Just like some of the code presented). Same for some developers: one-off timer function, boom! One-off input validation, bang! But when it comes to refactoring, you are now faced with a 1500-line script file or 30-ish files you don't even have a clue where they get used. They are painful to deal with. Frameworks, at least when you use them wisely, really help. You can, of course, achieve this with plain JS but a framework, just like design patterns, provides a baseline for conventions and communication.

[bokwoon]

I'm on board with using less JS but the solution is not a new html tag that must be supported by browsers... that's just screaming for it to not be used until it all mainstream browsers support it. The fragile towers of javascript are in fact the most reliable way to ensure your code works for a variety of browsers and a variety of versions.

[thescottyjam]

Alright, so we move away from SPAs. Then, we're asked to make our search box do real-time searches, automatically updating the results as you type.

Well, we likely can't just be pulling raw HTML every time a few characters are typed, that's way to much bloat to send over the wire, so we need to send JSON. And then, in the client, we'll need to turn that JSON into HTML somehow and add it to the existing page. Oh, and we'll want to update the route when the user's done typing. And... oh, whoops, we're back to having a SPA, but without the help of a framework.

Or, maybe, we want new to automatically show up while you're viewing a webpage, so you need to periodically poll the server to check for new information. Again, when that data comes in, you'll need to build the HTML for that and use it. Or, you know, your page has any sort of dynamic content, which is the hallmark of web 2.0.

Portals are an interesting step, but they don't solve everything. Frameworks like React do solve these issues. So, it's no wonder people keep turning to React, even for simpler websites - it's just easier to scale up from there, instead of trying to do hacky solutions like messaging data into a portal just to set a scroll position.

Is React overused? Certainly. And, for simpler projects, you probably don't have to worry about those minor UX things like setting the scroll position. React is certainly not the "ultimate" framework either. I like where Svelte is going, where it acts more like a language than a framework, thus leaving a much smaller footprint than its predicesors (0 byte download size). They're still young and have their own set of problems, so I wouldn't be surprised if they never get huge, and instead, some other new framework pops up and builds on Svelte's ideas. I think a framework like Svelte, or <yet-to-be-created> could solve a lot of these performance issues assosiated with React. It certainly doesn't take away the bundling step, but that's simply not going to go away, because minification, tree-shaking, etc is always going to be important.

[duztdruid]

Hasn’t aged well so far. Portals still not supported out of the box in any browser (including chrome).

[ionitaa]

This is so hipsterish it might actually get some traction...

[AndreiDinTheHouse]

Well, yeah, don't use a whole factory if all you really need is a hammer and some nails, sure. The message is clear and I definitely agree with it. But what really undercuts the message is that many of the arguments against are poorly put together. You don't need all the JS, but in fact most of the "no's" target frameworks. And most arguments are laughable at best. The server side is more powerful that the client side? For web apps that's hardly ever true. I've got 3-4 VMs with 2 vCPU and 4/8 Gb RAM to serve tens / hundred of thousands of users, but any of them on average can match the resources of on VM. ALL frameworks (JS or not) are naturally build to solve a repeating issue that a few people had back in the day. They grew only because more people found it helps with other stuff as well. That growth is incidental and rarely intended as such. But the thing is, it's the same on the server side. It's not really reasonable to say to always render server side these days when computing power at home is quite cheap, it's dedicated to running whatever app there is and in many cases you do want the user to also be able to use the app offline.

[claudiu-mm]

Since we're pulling stats from 2013 (that 1.1% stat), should we also build with IE6 in mind? I mean, IE6 still had a 5% share or something like that 7 years ago.

[allanwind]

The theatrics is distracting and I left the building when Prince was blaring at @26:54. It's a shame, really, as the speaker makes a convincing case for the title.

[exclusivect]

Tune down those obnoxious sound effects

[Zeturic]

Now you're thinking with portals.

[JohnnysaidWhat]

Love this talk. Down with frameworks! Down with bloat!!!

[Captainlonate]

I see a few issues in this presentation:

In the example of that 100+ page documentation site which "has no build system"... I think there are several issues. One, no way they build that without a CMS and WYSIWYG editor. Second, if it were actually 100+ unique .html pages hand coded, I can't imagine the nightmare of having to make structural changes that appear on every page, without a build system (partials).

I think you have two main gripes:

1) You think modern frameworks are too challenging to use, for simple sites.
2) You think we ship too much JavaScript to the front-end, which is computationally expensive and can lead to high transfer sizes.

So for #1, I think the benefits of a create-react-app site (maintainability, convention, babel for browser compatibility, resuability, etc.) far outweigh the messiness and DIY of hand coding every page from scratch. Obviously you shouldn't ship the react library if all you have is a few pages of static content... but then again, if that's all you're doing, then you're probably better off going with Wordpress or a drag-and-drop site builder anyways.

For #2, I think maybe you're just using the wrong tool for the job. In the example of that documentation site that only has static content, you should be using Gatsby. It generates static HTML/CSS at build time, which can be triggered by a CMS tool (like contentful or cloudcannon) which allows the non-dev editors to use a WYSIWYG. You get all the benefits of a widely supported framework, with an in-browser content editor, while serving up very fast mostly html/css static sites.

There's one more thing that will make it difficult for your framework-less movement to gain traction. Even though it definitely sucks that job requirements can span 1 page long for us web devs... it's also true that we're making a killing once we get a few years in and master them. It makes us more marketable, allows us to build even extremely complicated apps, and make serious bank doing it. So from my perspective, I'd rather have a challenging career that pays, than downgrade all my tooling, and go back to making 50k a year.

[durchschnittlich]

The audio mixing in this video could be improved. I jumped several times when the clips loaded in

[aleksandrpetrosyan]

Why aren't they extending HTML? Why can't we have a delcarative non-during complete language that handles Bling?

[karthikeyanak]

Possibly JS people created frameworks because they did not have proper understanding of HTML.

[pieterjoubert]

You can pollyfill this with an Iframe and a few lines of js (the downside is obviously if js breaks yo can't do the transition from portal to main page)
But he say you don't need js, He demonstrates setting the src in js, doing the css animation through js and call activate in js, which means if js doesn't work the portal still doesn't work.