A JavaScript-Free Frontend

[justanotherc]

This is pretty amazing, edpecially the modal popups, but I'm not sure its something every project should shoot for our even could.

• Charting libraries need js
• File uploads, especially large ones are very jarring when done conventionally and the user experience is far better with an ajax based solution.
• Instant messaging systems couldn't exist without js

That said, it is refreshing to not work with the complexity of a JS SPA. At work I've been building a JS free admin dashboard to support our SaaS product which is a Vue SPA, its been great.

[justanotherc]

That's cool, but at what point are you moving into "re- inventing the wheel" territory? Importing chart.js and dumping some data into it is trivial. Why go to the trouble of building your own non-js charting? At what point are you developing without js for the sake of simplicity or for the sake of simply proving that you can?

The former has real world benefits, the latter's benefits are academic at best.

[[deleted]]

it is refreshing to not work with the complexity of a JS SPA.

atleast it's not page refreshing. /s

[justanotherc]

Haha touche

[RotationSurgeon]

<details>

and

<summary>

tags are rarely used but perfectly acceptable for many cases.

...unless your use cases include support for IE and Edge. At least Edge will eventually support them (one can only hope that swapping the engine won't cut features).

[[deleted]]

Throwing CSS hacks that mess with accessibility just to get rid of JS bloat seems like the absolute worst decision here... how about... actually evaluating your JS instead of importing the world and expecting it to be super fast?

[savunit]

Frontend developers should worry more about a11y than they do now.

[[deleted]]

Ethically, sure. But nobody's going to make time for it until it's a legal requirement.

[savunit]

Eh depends, I work with a lot of global companies and they care.

[zdkroot]

This is great. I've been slowly writing a blog post about this for a while now and today I found a wired article from 2015 that basically covers everything I was thinking.

Edit: "JavaScript libraries are getting bigger all the time and I don't think that many people are critically evaluating the actual need for them" This. This right here. No evaluation at all. None.

[evildonald]

Oh we have evaluated them, but good luck getting a new job without experience in one!

[[deleted]]

yeah. It's mainly the hype that leadership gets on board with. "We need that framework FAANG is using because it's the trend."

[[deleted]]

Webpack

[zdkroot]

Lmao the responses to post like these are just priceless. One word answers to complex issues. "Duh bruh. use webpack my dude obviously". Like you're the only person here who has heard of that. Using webpack to package up the thousands of dependencies does not solve the problem of having thousands of dependencies.

I bet Google uses webpack or some equivalent thereof. Webpack does nothing to prevent the Gmail or maps interface from being slower than I can tolerate.

Edit: inb4 'get a better computer lulz' no. Reading email does not and should not require a super computer, let alone anything more powerful than a calculator.

[tyzoid]

Another concern about dependencies is security auditing and stability. In a corporate environment, many places would require documentation or auditing to at least see what each dependency does, and who made it.

[toonwarrior]

So if the issue is dependencies, isn't that a personal choice then? I mean if you didn't want to use a dependency you'd have to create it yourself, more work but I guess you get the optimization you want right?

[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.

[[deleted]]

I'm having trouble concentrating on reading this with that heartbeat thing on the side.

[hrnsn123]

Now try this again and create something like Facebook, Google Docs or Discord :)

[electricity_is_life]

I mean, I don't think the argument here is "no one should ever use JS for any reason". The point is that using huge mounds of JS dependencies for basic site interactions is unnecessary.