JavaScript Is the CO2 of the Web [audio]

https://changelog.com/jsparty/80

by feross • 7 years ago

105 124 7 years ago

changelog.com

pohl• 7 years ago

If anybody catches the titular moment, drop the time index here, please.

donio• 7 years ago

around 20:45

jefflombardjr• 7 years ago

Does this mean Svelte 3 is the Tesla of the web? No virtual DOM it's like it doesn't even use gas. XD

tl;dl around 20:45: They're comparing javascript and the tools you use for it to transportation modes. Saying things like Angular was the H2, React is the H3, vanilla javascript is riding a bike. They really are just saying don't over engineer things and use the right tools for the job.

Douglas Crockford's Javascript the Good Parts, is imo the best when it comes to getting a feel for what the right/wrong tools are. That book was a perspective changer for me. People like to get very passionate about frameworks and how Javascript should be done. JS The Good Parts made me realize it's better to play the strengths of what's available to you here and now. To accept the tooling as it is with its pros and cons - exploit the strengths and minimize the impact of the cons.

pier257• 7 years ago

He has some great points.

For 5 or so years I've been the guy who immediately started a SPA and I've turned 180 degrees. I now think SPAs are basically a cancer, with some exceptions where an app-like website is justified (Gmail, etc) or a hybrid app. SPAs introduce unnecessary complexity and bloat for the vast majority of use cases.

nop3• 7 years ago

JavaScript should be used like a condiment instead of a whole meal. It's led to the bastardization of the web in my opinion.

pan69• 7 years ago

Like, all we have for dinner is tomato ketchup.

steve_adams_86• 7 years ago

I'm with you. It occurred to me that what I love about things like react or vue has nothing to do with SPA capabilities. It's just developer ease in building reusable, composable, testable components.

I've had similar experiences with scaling too early into microservices for example. I need a seriously compelling reason to consider building around these paradigms now. The overhead is unreal.

Both great ways to solve a problem, but not really a problem I've yet encountered - ever.

I'm still glad I've had great opportunities to learn this, at least.

pjmlp4• 7 years ago

Thing is, building reusable components was always a feature of SSR Web frameworks since early 2000's, so there is no need for react or vue for bundle the HTML/CSS/JS that makes a fancy calendar widget.

And with WebComponents being supported across the board, even less so.

SomeOldThrow2• 7 years ago

The html version of gmail still works great! It also loads in under 30 seconds (near instantly for me) and is incredibly snappy. It also doesn’t look like a PM vomited google product integrations over the screen.

kchoudhu• 7 years ago

It also loads in under 30 seconds

Jesus Christ what is going on with the web.

cryptica3• 7 years ago

If you use the right tools, SPAs reduce complexity.

The problem is that most of the popular frameworks today add unnecessary complexity.

I still can't believe that we live in a world were most developers are OK to coding with a 5 to 15 second build delay and source mapping during development. I find is extremely frustrating. It slows me down and breaks my train of thought.

tluyben2• 7 years ago

If you use the right tools, SPAs reduce complexity

Like? I am curious: built a few SPAs (quite complex ones) and it sucked; I got the tools/frameworks from HN.

If you use the right tools ‘tradional’ websites are not complex either.

pier257• 7 years ago

If you go the SPA route you have to, at the minimum, add some form of routing and manage application state and logic. It doesn't matter how good the tools for doing that are, there is always going to be an overhead to do that.

quickthrower2• 7 years ago

There is so much entertainment in SPA vs HTML and similarly Vim vs Visual Studio, static vs. dynamic types etc. debates. But to be boring (sorry!) it all comes down to the most approriate tool for the job. At work it's a SPA because it's an application delivered via the web. Delivering via not the web wouldn't work as well, and delivering it as not an application is a non starter.

My current side project is a HTML sprinkled with JS, turn off JS and you can use most of the site kind of thing. Why? Because ... well mainly SEO to be honest. But there you go ... reasons!

samcday• 7 years ago

Bah, to hell with your boring moderate stance! I would much rather have endless debates with others about why MY hammer is better than their hammer, and ignore the fact that maybe not everything is a nail ;)

azdacha• 7 years ago

Google recently updated their crawlers to understand "full Javascript websites" ; I don't like the term spa as one could build one with pure css and html and still have a single page.

Now onto the js frameworks, it depends on which one is used. One could build a website watching web.dev and use a budget to make sure it's app is lightweight. There are numerous tools to make sure an app is properly made. But tbh, I like my js framework because the community is so great, I know the framework is good even tough there are arguments there and there.

I guess it all depends on the tool you choose and how you build your end product. Now having a website that loads in 30s is a joke I haven't experienced in the modern web, and my js framework actually provides a powerful caching system that makes the website available even tough I could bring down my dns. To this point I presume we are just in a odd point in web evolution where we have discovered a new paradigm and rushed into it's usage without maturity.

These things will change but I think it is important to know that some JS front framework are not incompatible with a lightweight web.

TeMPOraL6• 7 years ago

But to be boring (sorry!) it all comes down to the most approriate tool for the job.

It does. But, depending on how you look at it, either most web companies absolutely suck at picking right tool for the job, or the job isn't really what you'd think it is.

Taking your typical plain webpage done as an SPA, you could either say (as I would) that the authors picked wrong tool for the job, introducing completely unnecessary complexity both on their end and customer end - or, you could tell that the job of that website isn't to be useful to and considerate of the visitor, but to be e.g. CV-fodder for web developers, a way for the team to show off their sophisticated infrastructure, or for the marketing to play their A/B testing shenanigans, or for the company to show off to the investors, etc.

Once you account for all the "parts of the job" that are orthogonal or even opposite to delivering value to users, suddenly a proliferation of frontend complexity makes perfect sense.

pier257• 7 years ago

I agree completely, use the right tool for the job, it's just that the SPA pattern has been abused.

javajosh• 7 years ago

"SPA" is a fine, if difficult, architectural pattern. One needs to make a distinction between the processes and tools, and the pattern itself. SPAs are bad because of how they are built; personally, I blame the rise of front-end build tools for this. When it's easy to add dependency after dependency, then you get a bloated nightmare. Transpilers don't help, either, since they just remove you even further from "bare metal" of the browser, which is itself already at a dizzy height from the bottom. You might say that modern javascript programmers are too high, so to speak.

jaehong• 7 years ago

so, http is the methane(ch4) gas on the internet?

austincheney• 7 years ago

Then I guess the DOM is the radon of the internet, because most JS developers have no idea what it is or what its for and are scared to death to approach it without 3 layers of abstractions plus safety scissors.

dom - https://dom.spec.whatwg.org/

radon - https://en.wikipedia.org/wiki/Radon

TeMPOraL6• 7 years ago

Arguably, JS should be methane, and HTML should be CO₂ - the gas that's an important building block of life, and to which methane eventually breaks down (after doing its thermal damage to the planet, of course).

(Then, web developers would be cows, and web fashion/standards would be food for said cows; unlike in real life, here we transitioned from algae-based food to whatever farmers shove into livestock today, making the cows start burping large amounts of methane in the process. NPM would be an open-air landfill.)

threatofrain• 7 years ago

Relevant discussion titled "Why I'm still using jQuery" (27 May 2019, 237 comments):

https://news.ycombinator.com/item?id=20021289

brylie11• 7 years ago

I'm wanting to enhance a server-rendered template with a bit of JavaScript to fetch data from the server and update the DOM.

I like that Vue can be "dropped in" to any HTML page, like jQuery, without completely taking over the frontend development process, but it still weighs in at 30k. Also, the Vue docs are primarily oriented towards a pre-processing SPA workflow.

Are there any light-weight libraries like Vue, around 2k-5k, that enhance static HTML with declarative DOM manipulation reactive data binding?

Is there a "plain JS" approach to declarative DOM manipulation?

brylie11• 7 years ago

Correction, Vue minified and gzipped seems to be around 20k, so might still be my best bet for sprinkling declarative DOM manipulation into the static HTML.

Is there perhaps a library in the 2k-5k range, or somehow a way to use only specific parts of Vue (like a custom build)?

timwis• 7 years ago

https://github.com/choojs/choo

goatslacker• 7 years ago

I’ve been enjoying the simplicity of keeping it plain using lit-html. It lets you write declarative markup and they’re template literals.

brylie11• 7 years ago

Thanks for the suggestion :-)

scarface74• 7 years ago

I’ve used HandlebarsJS for the same thing. I can’t imagine you can get much simpler.

motogpjimbo• 7 years ago

ES6 template strings make a reasonable templating language and are built-in to most browsers nowadays.

ploxiln• 7 years ago

Keep a sense of scale. 30 KiB is small. If all the libraries you use add up to less than 50 KiB, then really, no one will notice.

Think of a "modern best-practices" site that uses a big framework and some big addons and feature libraries, and ends up with like 500 KiB of JS. Some end up with megabytes! That's crazy. I think these developers don't have a sense of scale. They probably think I promote premature-optimization, that they're good engineers who follow best practices and use best-in-class tools and techniques ... but they don't have a sense of scale to see how the results are not reasonable.

30 KiB is small. 100 KiB total is probably quite OK. 500 KiB is very fat. 2 MiB is crazy town. Sense of scale :)

brylie11• 7 years ago

Good perspective.

I can probably stick with the 20KiB Vue dependency, particularly when it doesn't require any build system or other dependencies.

spankalee5• 7 years ago

lit-html lets you write declarative, reactive templates in plain JS, and is ~3.3k. Check it out here: https://lit-html.polymer-project.org

rbanffy2• 7 years ago

That sayHello function declaration burns my eyes.

Why?

brylie11• 7 years ago

Yeah, I was excited about Polymer when learning about Web Components.

I'll read more about lit-element. Thanks :-)

kreetx2• 7 years ago

I also like that it comes with no virtual dom, but just remembering direct references to the "holes" that need filling. It's funny that vdom has gotten so much traction albeit being inherently inefficient.

jamil72• 7 years ago

Hyperapp gives you a declarative model in a tiny framework (around 3.5kb) inspired by the Elm architecture. https://github.com/JorgeBucaran/hyperapp

brylie11• 7 years ago

Sounds cool. I'll check it out :-)

reactor• 7 years ago

May not be exactly what you are looking for, but take a look at https://svelte.dev/blog/virtual-dom-is-pure-overhead if you haven't seen already.

and this https://youtu.be/AdNJ3fydeao

brylie11• 7 years ago

Yeah, I really like the idea of Svelte. I'm just coming from the perspective of wanting to sprinkle in a little JS in my development flow, and avoid pre-processors or compilers, if possible.

mhagemeister2• 7 years ago

There is also Preact which is a 3kb alternative to React with a similar API. https://github.com/developit/preact/

Disclaimer: I'm one of the maintainers.

brylie11• 7 years ago

Thanks for the suggestion. Really great work keeping the framework so tiny! :-)

Can Preact just be "dropped in" to an existing HTML template, like jQuery?

kreetx2• 7 years ago

If it's smaller, faster and react-compatible, then are there any downsides? Otherwise a switch would be a no-brainer.

jammygit• 7 years ago

I just write the DOM updates into a controller layer’s setter functions, or use event listeners. I find it easier to work with than angularjs, but haven’t used angular 2+ or react so maybe I’m missing out on something.

Basic MVC goes pretty far

mardix• 7 years ago

Check out reLift-HTML, https://github.com/mardix/relift-html, A very small (3kb) view library that allows you to create Web Component, Custom Element, and helps you make any HTML page reactive without the bloat of big frameworks.

uxcolumbo• 7 years ago

So what's the view on using Gatsby for building content or ecommerce sites?

Better than using other static site generators sprinkled with JS?

I've not done any research yet, so curious to know what the HN community thinks.

finchisko• 7 years ago

I don't get the sentiment about JS. Where all the hate is coming from? Maybe it's just confusion. People hate SPAs, but talking about web. IMO web and SPA are two different things. Maybe overuse of JS on web sites is problem, but A in SPA stands for "application". And applications written in JS are perfectly legit to me.

goatlover• 7 years ago

One complaint is developers defaulting to using SPAs for building traditional websites which aren't apps, recreating the functionality that modern browsers are already good at, and there's plenty of good backend frameworks that have been around for while, where content can be loaded quickly, so a full page load isn't a big deal as long as it doesn't have a bunch of JS it has to wait on.

altfredd• 7 years ago

What is there not to get? Javascript in browser simply sucks as platform.

1) No memory limits (technically, there is a limit, but it is much bigger than, say, app heap limit on Android)

2) Background tabs can use setTimeout() to indefinitely run code long after user left them

3) Websites can start background processes (Service Workers) without user oversight. Users can't prohibit that or kill them via easily available means.

4) Applications are non-optimized by default, need massive CPU resources for JIT-compilation

5) Rendering a page with five sentences requires executing tons of said unoptimized code.

6) No permission system for majority of things. All important user controls have to come with browser add-ons.

7) Applications can update themselves anytime without user consent

8) Most web apps do not work offline

9) Everything is tied to proprietary web services with overarching surveillance and dodgy EULAs...

marcus_holmes3• 7 years ago

take literally any language, and there's a laundry-list of complaints about it.

there was a whole thread here a few weeks ago hating on SQL (a battle-tested veteran of ~50 years) and giving a laundry-list of "things that are broken in SQL"

there are routine threads discussing the manifest flaws of Go, and why everyone should switch to Rust/Elixir/Nim/whatever the newest flavour is.

no language is perfect (not even LISP), every language is a bit broken in some ways.

JS is a great language for its role. It allows newbie coders to write some godawful web code that works!!!1!1!! while they're learning (without having to understand a lot of CS), and veteran coders to write some really elegant code if they want.

Learning to use JS powerfully has been a great education in coding for me. I'm still not using it as well as I could be using it, and I like that it has depths still to discover.

krapp3• 7 years ago

Every item in your list describes a problem with the way browsers are designed, with the way the web works, or with the standard practices and incentives of web development culture, and all of them would likely still exist were javascript replaced with any other language.

It's ironic that JS as a language is hated to the point of near derangement on HN while being the least relevant component of the problems people here have with the modern web.

tjpnz2• 7 years ago

I'm working on a dashboard for a personal project. It involves a few dynamically populated dropdowns and a map with custom markers. In the past I might've used jQuery and maybe Backbone in more extreme cases. After looking into the "modern" options available I ended up writing the damn thing in jQuery. I did it in a few hours without having to involve Node, npm (or yarn), hundreds of dependencies (and associated security concerns) or "(com|trans)pilation)" of anything. The whole process reminded me again of why I went from fullstack to working exclusively on backends years ago.

artiscode• 7 years ago

Out of curiosity - did you chose jQuery because it's so ubiquitous or was it the better choice? There are frameworks like vue.js where you don't have to deal with node, yarn, explicit dependencies and transpilation, that offer virtual DOM and have very little overhead.

tjpnz2• 7 years ago

Better choice ultimately but I suspect the hype around "modern" everything these days would still lead a lot of people in that direction, even for simpler things like this. I did briefly look into Vue and didn't completely hate it. Although the docs (at least from my cursory glance) were suggesting you would need Node to get up and running with it. Good to know it doesn't need to be that complicated.

TeMPOraL6• 7 years ago

Good to know. For small personal things that need JS, I too tend to just go for jQuery, or increasingly stick to vanilla JS. React is ridiculously overcomplicated for small projects[0] IMO. I always thought that Vue is just a React competitor/copycat, so never bothered to investigate it. Since you say it offers more lightweight vDOM with no JS NPM tooling bullcrap, I'll look into it, so thanks!

[0] - I used React a bit, and I can only stomach it when working with ClojureScript, which gives some sanity to the syntax and language - but that's another pretty large and very complex dependency to be included in the pipeline!

pier257• 7 years ago

For these cases I like to use Vue with a script tag. It's smaller than jQuery, probably more convenient, and depending on your use case you can get away with writing ES6 with no babel.

tannhaeuser• 7 years ago

I don't know, on the one hand, JavaScript is without doubt neccessary for a lot of useful things on the web. OTOH, I always thought of JavaScript as a way to get a better declarative web long term, by experimenting with UI paradigms and trying things that eventually can become part of new declarative HTML UIs. But that feedback into HTML never happened, and it seems we're stuck with an incredibly poor language we're enslaving the next generation of both users and developers in. The worst part is IMHO where we attempt to shoehorn JavaScript into a "serious" language with ES6+ classes, modules, new syntaxes, type decorators and what not; all we've achieved with these inessential extensions is to make future browser implementer's life difficult.

I haven't listened to the audio, but all it takes to get rid of JavaScript-heavy pages (that only exist because young webdevs are being taught and drool about mostly JavaScript, React, and other overkill rather than web basics), we just need to step up the game and demand power-efficient webapps, or no webapps at all.

davidjnelson2• 7 years ago

Experienced engineers use react when it is needed for the enhanced ux. JavaScript is actually a decent programming language if you use the functional paradigm and read enough books and ship enough products to understand its strengths and weaknesses. It’s even better with typescript.

zaro3• 7 years ago

So Javascript is the problem? Not the trackers, and ads but Javascript which is simply a programming language. May not be the best, but its not the worst either.

boomlinde• 7 years ago

So the rats and lice are the problem? Not the plague?

0xDEEPFAC3• 7 years ago

Javascript was a poorly thought out language designed in two weeks. It is a problem... so much so that features keep getting stacked on it because by now we are stuck with it.

It is such a mess that it is now mainstream to compile some metajs langauge to js.

Is it the worst language every created? Certainly not, but is it the worst language being actively developed and used? Yes. Is it poisoning the minds of young programmers with bad practices and a fear of concurrency? yes.

starbugs2• 7 years ago

The first prototype was designed in 10 days. The language itself underwent several iterations and I think it's not fair to say that it was "designed in two weeks".

Other languages (and newer versions of JS) compile to ES5 so they can be run in JS engines supported by commonly used browsers. Not because JS itself "is such a mess". This allows one to roll out new language features to developers without having to wait for browsers to pick up a new standard (or language). Pretty much every language I am aware of adds new features and changes over time. Do you call them a mess also, because they make changes?

I think your comment is highly opinionated, not well supported by facts and sources, and IMO on the edge of being insulting to a lot of people.

narag• 7 years ago

Javascript was a poorly thought out language designed in two weeks.

The problem is not JavaScript the language, the problem is abusing client side programming. I can't imagine what kind of perfect language could have prevented that. If you can, I won't believe you, sorry. The feature that matters, sandboxing, it's there yet.

zaro3• 7 years ago

Most languages are terrible in nitially. More important I think is the ability to evolve.

And JS is evolving, faster in some areas than others but it is evolving. Compared to the first time I used JS, now its very convenient language with some quirks. But the main reason actually it is rising in popularity so much is that's probably the most cross platform language today. And I am ot talking about what you compile language to, I mean what do you use to ship software to people.

TeMPOraL6• 7 years ago

Well, CO₂ is also a fine little molecule that's crucial to most life on Earth. The problem with CO₂ isn't the molecule, it's the amount of it being released, and that despite the dangers being widely known, the market is greedy and just doesn't care. It's the same with JavaScript - the language is what it is. But the ads, the trackers, the Node tooling, the ever-increasing frontend bloat, the user-hostile design stemming from it - these are the problems.

zaro3• 7 years ago

I don't see how you can put ads, trackers and node tooling in the same basket. Also the node tooling is helping to contain the frontend bloat.

cryptica3• 7 years ago

I think that VueJS is a great framework because it's very flexible. I love being able to build entire apps without a bundler and no build step. I hate bundling during development. It's so slow.

neya2• 7 years ago

I urge you to use a well designed language like Elixir. And work with a well designed Framework like Phoenix. And then try to use Javascript for once. You'll see how fragile the language itself is, let alone its eco-system.

No, I'm not a JS hater, In fact I LOVE VueJS and I think you can do a lot of great things with it. For example, I built a completely offline cart system without any server backend using just VueJS. But then, between VueJS and something like LiveView, I find its infinitely easier and faster to develop on vanilla server-powered CRUD applications than SPA/JS only frontends with "serverless" backends.

With each year in web development, the complexity only seems to keep increasing to get something as simple as loading a web page fast or without refresh.

These days, I've started using LiveView and Turbolinks which basically means I have absolutely no necessity to touch Javascript at all and I can get everything done with the same language I write for my backend - Elixir. It's pretty amazing.

Much love to José and Chris.

amelius• 7 years ago

Languages do not have to be "amazing" to be useful.

Also, being able to use the language directly in the browser is a pretty useful property.

neya2• 7 years ago

It's really not genuine to label a language "useful" if it's the only option you've got.

marcus_holmes3• 7 years ago

I'm building a web product.

The static pages are in static HTML, because of course they are.

But the product pages need to be interactive. To do that, I need to use JS, and an SPA framework (I use Vue) makes that easier and way less effort than (e.g.) JQuery.

I have one problem, though... the marketing folks want to be able to change the copy on the static pages, but they don't want to learn HTML. They're pushing for me to implement the static pages as a Wordpress site, with a list of pluging that they want, because that's what they're used to.

I don't think JS is the problem here...

xwdv• 7 years ago

It’s fairly trivial to setup a simple text file with all the websites copy so that when the file is updated a script can automatically fire to rebuild the static pages and deploy it.

zbentley• 7 years ago

That doesn't answer the marketing folks' concerns in GP. They don't hate HTML because they prefer markdown or whatever; they want a WYSIWYG/drag-and-drop site builder because it's what they're used to.

pier257• 7 years ago

Vue is not an SPA framework. Vue only makes components with data binding and reactivity.

Vue Router, a plugin, adds the SPA functionality.

marcus_holmes3• 7 years ago

good point. I haven't quite gone that far, but it's on the trello board for consideration ;)

mmcnl• 7 years ago

I'm tired of discussions concerning "Javascript" and "the web" where absolutely conclusions appear to be drawn. JS is a language, the web is a platform. Ofcourse overusage of JS results in annoying bloated websites, but when you want to build interactive applications that can easily be distributed to the entire world, the combination of JS + web is a virtue. The web isn't only for displaying static content, it's time to accept that.

tjoff• 7 years ago

I'm all for dynamic content, as soon as anyone can find a decent use-case for it.

indalo• 7 years ago

Yeah, I've never understood the yearning for effectively plain text html. I remember recently a submission that had a "brutalist" styleguide.

I wonder how much of this is a reaction to the complex and volatile nature of frontend patterns, in a psychological sense.

JavaScript Is the CO2 of the Web [audio]

Related Stories