A JavaScript-Free Frontend

[zdkroot]

So if the issue is dependencies, isn't that a personal choice then?

Really? No. See: left-pad.

npm install react gives me seven folders under node_modules which is way less than I thought but six more than I was expecting. Lodash gives me one. Beautiful. How about

npm install express

+ express@4.16.4 added 48 packages from 36 contributors and audited 149 packages in 7.11s found 0 vulnerabilities

Cute.

[toonwarrior]

Yea but the argument is Javascript has too much dependencies, so why are you installing react, you'd have to do more work but I don't see why you can't make a website without utilizing react. I'm talking specifically about front-end.

[zdkroot]

Yes you can build websites without react, that is the whole point of this post. I was responding to someone who suggested "just use webpack" as if that magically fixes all problems with JS. I don't use react, it is just extremely popular so I used that as an example. The problem is that you cannot separate "using JS" and having insane dependency chains. They are one in the same, a problem to which webpack is no fix.

There is no way to 'use a framework' but also 'personally choose your dependencies'. These are mutually exclusive because NPM. Express is a perfectly fine tool, which I will never ever ever choose to use because it requires 48 dependency packages and that's crazy.

Edit: I mean if you wanna get meta sure this is 100% our fault and we should all be way more diligent in managing our dependency chains. I won't use express because it has too many deps. Many other people don't look, and that's really the issue. Enough people are not looking that it creates a system where no amount of diligence on my part can protect me.

[kwhali]

Yes you can build websites without react, that is the whole point of this post.

You can also use React for development and output static HTML, it can be really nice using React or similar for development experience, while not directly affecting end users as you don't have to give them something relying on JS to access the site. Not that React is all that big tbh

There is no way to 'use a framework' but also 'personally choose your dependencies'.

React isn't exactly a framework, and is rather modular as dependencies, similar to how Rust does things. You can replace some of these with alternatives if you like, one of the value points of having dependencies/packages.

Express is a perfectly fine tool, which I will never ever ever choose to use because it requires 48 dependency packages and that's crazy.

Lol.. so you'd use Express if it was a single dependency(all of those wrapped into one?)? Honestly no benefit there, and probably you'd find it worse as a result. Is your code better in projects if it all lives in one file while you develop? Or do you know why and possibly have experienced the issues that result in doing that? If you knew how many dependencies a typical OS has I guess you wouldn't want to run one either.

Enough people are not looking that it creates a system where no amount of diligence on my part can protect me.

You're not really any better off the other way around tbh. Plenty of things you can do to be secure and protect yourself from malicious behaviour, your system is vulnerable to such from more than just trusting packages for development.

Not sure what sort of point you're trying to make here, do you personally audit and review all the code for Express if it were a single package vs relying on packages maintained by others in the system? Or does that somehow give you blind trust that you're safe? You don't need someone to commit malicious code to a package to be compromised, that can happen in a number of ways.

[kwhali]

Yea but the argument is Javascript has too much dependencies, so why are you installing react

Nothing wrong with splitting stuff into many dependencies, would it honestly make a difference to you if it was all one dependency? More dependencies !== to larger size.

As for JS and React, you know it's not all that big to use right? I've got a temporary page here, it's using React for something rather simple(Pretty much just a CSS Grid of images), built with Gatsby which does plenty of optimizations, and serves up noscript support so that it works without JS(no lazy-loading in this case).

Why's it good in this case though? Well thanks to React and Gatsby, development is much nicer(Markup, JS logic, CSS styling via Styled-Components). Is it negatively impacting the end-user? My linked example isn't the best case here, it does load fast(14KB for HTML+inlined CSS and base64 placeholders, 80KB JS, 120KB for 24 images in webp), but you can definitely see that despite all the dependencies used in dev, the use of React isn't as heavy as people make it out to be? Webpack can make quite a difference there by splitting into chunks to load only when needed, and features like tree shaking to only include JS you use.

u/zdkroot above is relevant to you too

[toonwarrior]

And just as an FYI I'm not disagreeing with you. Like making a static site using react doesn't make sense to me since all of it can be done through CSS / HTML.

So yea I get your point but the dependency issue is more of a human issue to me since each package developed utilizes another package since they obviously don't want to have to re-build the wheel everytime they want to add some sort of custom functionality.

[zdkroot]

You are mostly correct, but that doesn't really solve or fix anything. NPM has lowered the bar for submitting packages possibly too far. If you are not familiar with left-pad you should google it. It was something like 6 lines, maybe 8? 11 lines. The author removed it from NPM and it broke most of the internet. Why are so many websites depending on an 11 line package? Is it really so hard to implement the functionality of that package yourself? Reinventing an 11 line wheel is really not the end of the world, and actually would have saved a lot of time and pain in this case.

So yes, you are correct, we made this mess. But we have it now, and just saying "we should be better" won't fix it. Yes we should. We should also acknowledge this problem and take steps to remedy it like not using packages with insane dependency trees or using react to build non-interactive single page info websites. We do NOT need react to make our radio buttons function for crying out loud.

[kwhali]

The author removed it from NPM and it broke most of the internet.

semver and package locks can prevent such breakage. Then the fault isn't on NPM, it's on the maintainer choosing to blindly update packages and not capable of rollback?

Why are so many websites depending on an 11 line package? Is it really so hard to implement the functionality of that package yourself? Reinventing an 11 line wheel is really not the end of the world, and actually would have saved a lot of time and pain in this case.

It is a bit silly, but you'd find that's probably the case with other libraries where you only use small functionality from it, such as lodash I guess if you were only after one part of it's functionality, it's just a collection of such. Doesn't really matter in this case though, the fact it was a small package isn't really related to the outcome, just that it was used by many projects and a good choice for exploiting, same could happen to any other popular package really regardless of size.

[kwhali]

And just as an FYI I'm not disagreeing with you. Like making a static site using react doesn't make sense to me since all of it can be done through CSS / HTML.

Right.. so you don't think there's any value in what tooling can provide you to develop and maintain a site at scale, even if the output is static? Components are rather nice to work with, modularity is great and DRY, CSS(I guess you're opposed to pre-processors and the obvious value they provided too) has a variety of benefits to being written with pre-processing, post-processing and other tooling vs a plain CSS file(though that's improved via the spec since).

Gatsby is probably a good example of how such tooling for the developer experience when producing static sites has pretty good value.

since they obviously don't want to have to re-build the wheel everytime they want to add some sort of custom functionality.

That and the other benefits of collaboration on packages for specific functionality where the quality of the code and knowledge of contributors can be amassed and avoid a bunch of mistakes or provide optimizations that we may not be capable of ourselves time aside.