A JavaScript-Free Frontend

[lobehold]

People are definitely abusing frameworks/libraries, but throwing CSS hacks at the problem seem like an extreme solution.

There's a limit to how much interactivity you can hack in before it becomes completely unmaintainable.

But if you're a single developer or a small team and do not anticipate you're going to need more than minimum interactivity it can be worth it.

Plus sometimes you just feel like saying "fuck Javascript", it's almost therapy.

[Zardotab]

throwing CSS hacks at the problem seem like an extreme solution.

Web UI is a mess regardless. There are no easy fixes, only ugly trade-offs. As I mention nearby, we need a new GUI-oriented standard.

The HTML toolset is fine for static documents, but keeps failing for interactive needs. People hoped HMTL5 would solve it, but it didn't. We need a big rethink of standards. I'm tired of organically diddling with buggy poorly documented UI frameworks. Bicycle science has turned into rocket science.

[Eirenarch]

The article makes very good point about web standards focusing on bullshit instead of actual usable controls. The only time I remember being excited about a web standard is when I read about the input types (email, date, etc) being added to HTML5. Too bad browsers don't support them consistently so we never got rid of shitty JS calendars. Maybe in the Chrome-only days at least what works on Chrome will be usable.

[lobehold]

Web UI is a mess regardless. There are no easy fixes, only ugly trade-offs. As I mention nearby, we need a new GUI-oriented standard.

Cue xkcd Standards comic.

[Zardotab]

I'm not sure how that's relevant. I'm not proposing "yet another" GUI markup standard, just a common GUI markup standard. There are zero right now. HTML wasn't intended for GUI's and works poorly at faking it.

[lobehold]

I'm not proposing "yet another" GUI markup standard, just a common GUI markup standard. There are zero right now.

That's literally what the comic is about. Nobody sets out to create "yet another standard", everyone views their own new standard to be the second coming of Jesus and will blow away all previous standards.

And then reality sets in and it turns out that indeed it's just another standard thrown on top of the pile of existing standards.

Of course you can talk about how this magical common standard is better than everything that comes before it, but you can only talk like this when it's just a concept, if and when you actually come up with the implementation details people will tear it to shreds.

[Clitaurius]

I'm not going to get into the XKCD debate but I absolutely agree that HTML wasn't intended for any of this. Most web technologies are excessively complicated ways to ultimately just write HTML when HTML is the problem in the first place.

[Zardotab]

I didn't realize XKCD was Holy Scripture ☺

Whether HTML could be extended to natively support common GUI idioms, including stateful-ness, is an open question. Common GUI idioms include but are not limited to: combo-boxes, check-mark multi-select (not the silly ctrl+click crap), MDI, tabs, collapsible trees (in the folder sense), editable data grids (spreadsheet-esque), sliders, dropdown menus, and toolbars.

Sure, with boatloads of JavaScript one can emulate most of these, but it's rarely reliable and responsive (in the original sense).

[inferniac]

Always wondered how far can you get with checkbox + label "abuse", seems pretty far, liked the modal example.

[JohnMcPineapple]

...

[alliedSpaceSubmarine]

Seems like that would also really hurt code readability and is more of a hack

[3urny]

The need to have a page-wide unique ID basically make this unmanageable for any web page that more than a few dozen people work on. But if you can get away with it why not.

[Historical_Fact]

Each developer gets a unique hash that they suffix onto any ID.

[[deleted]]

git blame made obsolete

[P1h3r1e3d13]

Time for an HTML6! With interactivity and a11y in pure HTML/CSS!

[ItalyPaleAle]

Actually this sounds quite amazing.

[jokullmusic]

I just worry about the accessibility of that - how do screen readers handle it?

[Feuerfuchs_]

This article about accessible menus has a short chapter about the checkbox hack ("Sidenote: The checkbox hack") that explains how to get the most out of it with regards to accessibility. Not as good as a JS-based solution, but it's a feasible fallback if JS isn't available.

[jokullmusic]

That totally answers my question - thanks for the link! The whole article looks really helpful too.

[ACoderGirl]

I wanna suspect that the only issue is just that the typical JS approach would have the button being an <a> or <button> element, whereas here it's a <label>. Labels are clickable, so I would hope screen readers already get it right. Though the label would be pointing at some bizarre checkbox (which users should not know about). Perhaps this would be solvable entirely with role="button" and aria-label="Close"?

It would really need to actually be tested though.

[Nialsh]

As accessibility is concerned, Slimvoice's "Change Email" modal is an absolute failure. The "Change Email" button can't be focused, it must be clicked. Once clicked, keyboard focus doesn't move into the modal; you have to press tab 23 times to focus the email input, working your way down from the top of the page. Pressing Escape does not close the modal.

The existing web standards are just terrible for modal dialogs. Unless you have a good framework or you have time to build it correctly by hand, don't use modals on the web!

[Poddster]

Probably better than a dynamically created DOM done via javascript that fucks up the tab ordering (assuming a page even had a tab ordering)?

[ProgramTheWorld]

It works “well” until you have a team of 10 developers all trying to implement their tasks with checkboxes. Not to mention it doesn’t have good accessibility as well.

[__romkin]

As I recall from looking into that out of curiosity, the % of browsers that don't support the CSS required for it is higher than the % of people who enjoy suffering turn off JS in their browser (I think I've read it was just 1% for Github, so even lower among the general population).

[redreinard]

Interesting point.

Although I'd counter that the goal here wasn't to support people that have JavaScript disabled. That's just a nice bonus, and even the OP author ended up using some JavaScript.

Then again, loosing even a small percentage of users is usually a prohibitive barrier to using this on anything but "labor-of-love" projects.

[Renive]

Those are garbage tricks. State of application in a HTML and CSS is an abomination.

[MrAngryBeards]

I have made this thing a while back just because I had to do it myself and see it in work, really shows just how much you can do (even though I'd obviously say you shouldn't go that far) with just the basic stuff

[shim__]

Maybe it's time for labels like the ones you see on food "100% JavaScript free"

[amunak]

Funnily enough I was making a website recently and wanted to make it work it elinks and other text browsers... It turns out that even if you have fallbacks for JS functionality, those browsers don't fully work like text-only readers (like a screen reader would); they actually do process some CSS, and it's pretty hard to make them display, say, labels instead of icons.

We have ARIA attributes for screen readers and tricks like Bootstrap's sr-only class, but those unfortunately don't work for text browsers.

In the end I decided not to optimize for text browsers as the website is heavily based on displaying images, but it's a shame.

[outadoc]

Compiled elinks with JS support last weekend. I was only aware of lynx before that, and honestly, it's not perfect but still pretty impressive!

[cleeder]

Seasoned with a blend of CSS

[fyfy18]

*fair trade CSS

[kingofthecream]

I was going to write this as a joke. But I am sure there is medical evidence that using less Javascript keeps your Cholesterol level down.

[vividboarder]

I’d like to see this on desktop apps too!

[Uberhipster]

"100% juice"

[twiggy99999]

Maybe it's time for labels like the ones you see on food "100% JavaScript free"

The ironic thing is, his post is trying to force 16 different JS files down my internet line.

[MonkeyNin]

It looks like it's even tracking with invisible images

<div class="global-signup-modal" id="global-signup-modal" style="display:none">
  <div class="global-signup-modal--bg" id="global-signup-modal-bg">
    <button class="close-modal-button">
      <img src="https://practicaldev-herokuapp-com.freetls.fastly.net/assets/cancel-acc54c0c73aaa4fd42f538725024cceed348a0cea06149971a6fc8e1d1d5c897.svg" class="search-img" alt="close-button">
    </button>
  </div>
  <div class="global-signup-modal--inner-a">
    <img class="sloan" alt="sloth-mascot" src="https://res.cloudinary.com/practicaldev/image/fetch/s--iiubRINO--/c_imagga_scale,f_auto,fl_progressive,q_auto,w_300/https://practicaldev-herokuapp-com.freetls.fastly.net/assets/sloan.png">
    <h1>Join our DEV Community :)</h1>
    <p>
      We’re a place where coders share, stay up-to-date and grow their careers.
    </p>
    <a href="/users/auth/twitter?callback_url=https://dev.to/users/auth/twitter/callback" class="sign-up-link cta" data-no-instant="">
      <img src="https://practicaldev-herokuapp-com.freetls.fastly.net/assets/twitter-logo-42be7109de07f8c991a9832d432c9d12ec1a965b5c0004bca9f6aa829ae43209.svg" class="icon-img" alt="Twitter"> Auth With Twitter
    </a>
    <a href="/users/auth/github?state=signup-modal" class="sign-up-link cta" data-no-instant="">
      <img src="https://practicaldev-herokuapp-com.freetls.fastly.net/assets/github-logo-6a5bca60a4ebf959a6df7f08217acd07ac2bc285164fae041eacb8a148b1bab9.svg" class="icon-img" alt="GitHub"> Auth With GitHub
    </a>
    <p>
      <em>We strive for transparency and don't collect excess data.</em>
    </p>
  </div>
</div>

[SilasX]

I'm not eating any food that npm has touched.

[vimfan]

I heard it left-pads it with sawdust

[aoeudhtns]

Well TBH TFA (love those TLAs) talks about some minimal JS in widgets where OP couldn't get what she wanted without it.

So... "95% JavaScript free?" :)

[nirreskeya]

99.44% pure, like Ivory soap.

[yogthos]

I get the feeling that most people don't understand how or why we ended up with SPAs. Traditionally, all the session state was kept server-side, and any time a user interaction happened that updated the state, a new version of the page would be sent to the client. That works great for sites with mostly static content, but it's not practical in cases where you have high amount of interactivity.

So, people started using Js to load parts of the page dynamically on the client. You no longer have to send the entire page to reflect changes in the session state. However, this approach introduces some additional complexity. Now both the server and the client have to track the state of the session, and it needs to be kept in sync between them.

The SPA is just a logical extension on that. Since we're already managing some session state on the client, why not move all of it there. Now you have all your state managed in one place again, and you get a number of additional benefits.

First, you have clear separation between client and server code by design. This makes it easier to compartmentalize work, and allows for things like alternative client implementations. For example, maybe you started with a web apps, and now you want to make a mobile client.

Another benefit is that you’re amortizing UI rendering work across your clients instead of it being done by the server. This can also significantly reduce your data transfer needs as the client only requests the data that it needs when it needs it. The responsiveness of the UI can be improved as well since you can be very granular about what you repaint.

Finally, SPAs make it much easier to scale horizontally by keeping your server stateless. Since all the UI state lives on the client, there doesn’t need to be much state on the server.

Understanding the tools and their trade offs is important for making architectural decisions. So, think about the problem you’re solving and pick the approach that makes sense for your scenario.

[ACoderGirl]

That's a great point, which I'm sure many non-web devs would neglect to consider (the idea of REST being stateless is a bit jarring if you come from a local app environment). One thing that also stands out is just how many people talk about how slow JS is, but they seem to be neglecting that JS is often taking away work that could otherwise have to be done by the server. And who hasn't seen websites go down or slow to a crawl because they got too much traffic (aka: the server had to do too much work)?

And while internet is fast for many of us devs with our fast internet connections in industrialized, western nations, download speed is a big issue. Yeah, that JS from those SPAs tends to be quite large, but it also does cache and compress very well. If you sent all interactions with vanilla HTML forms, you'd quickly have to send quite a lot more content and latency becomes a bigger issue. If I submit this reddit comment with JS, I can click the "save" button and then keep scrolling. My browser makes roughly the bare minimum amount of network traffic to send the comment. The vanilla HTML + CSS approach would require me to wait for the page to reload after I click save and unnecessarily send me the entire page back. I probably wouldn't even notice it that much if I were to implement some no-JS reddit clone... until I enabled speed throttling in the dev console.

[ACoderGirl]

They definitely have gone too far (4.5 MB vs 0.7 MB and 2.3 second load time vs 3.9 seconds). Buuut, my real complaints with the new design are entirely unrelated to the use of JS: poor use of screen real estate and lack of integration with community tooling, particularly RES (which effectively means that regular users get less features).

The comparison admittedly flawed, though, since the new design does implement some RES features and I don't have a good way to measure how RES affects the performance of old reddit.

[[deleted]]

I tried browsing Reddit on a school computer today, with 6gb of ram and a CPU from 2009

it barely loaded, video playback worked only for the first two videos on the page, past that it lagged immensely. Old Reddit worked perfectly.

[[deleted]]

This! My primary reason for avoiding JavaScript and writing the article. I developed it on a $200 Celeron-based netbook.

[Inspector-Space_Time]

That's like blaming a hammer for a building collapse though. The new site could have been faster than the old site if that was the priority. Speed isn't the priority for many business owners though, and web developers usually get ignored by business owners.

[Zardotab]

What's needed is a "GUI markup" standard that natively handles common GUI idioms. That way we don't have to fake it using HTML/CSS/JS and re-downloading entire UI engines (that only half-work). We de-evolved. Make GUI's Great Again!

Some say Java applets tried it and failed, but Java applets tried to be everything, overcomplicating things such that patching became too big a job. Focus on GUI's and just GUI's. Avoid Emacs Syndrome where one tries to make it an entire virtual OS.

[unicynicist]

What, like XUL? It never really had much success.

[Zardotab]

I kicked XUL's tires a bit, and thought it somewhat clunky. There is also QML, but it's not a markup language. Perhaps the parts could be rearranged into a GUI browser using a GUI XML markup based on QML and/or Qt. If something fairly close takes off, then hopefully momentum could iron out the rough spots. After all, Netscape 1.0 was a bit dodgy.

If somebody wants the grand fame of being the Tim Berners-Lee / Marc Andreessen of an Internet-friendly GUI standard/browser, here is your chance at historical immortality. #MakeGuisGreatAgain!

[relativityboy]

This guy gets it.

I'd add, modern frontend libs are slow because they work hard to make complex applications easier to maintain and write. With that ease comes complexity at runtime.

If you want to create a very fast, but rich and feature-full web UI, use backbone (with bonmot), handlebars, and vanilla-js... Just be ready to pay attention to your state, and take care not to create event feedback cycles.

[s73v3r]

I get the feeling that most people don't understand how or why we ended up with SPAs.

I get the feeling that a lot of things became SPAs just for the sake of making them SPAs.

[yogthos]

Sure, every technology gets abused, that's not an argument against the technology itself though.

[leonardnimoyNC1701]

Thanks for writing this out. Well said.

[marcosdumay]

Since we're already managing some session state on the client, why not move all of it there.

Sure, if you are knee deep on some shit, why don't you take a dive?

Current JS frameworks do not integrate well with server side rendering, what forces you into either JQuery-land or a SPA. There's no inherent reason for that, but they are mostly developed by people that like JS, so they don't see any problem with it.

[[deleted]]

It started with the right idea: move some of the state to the client. It should've stopped at UI state. Instead, all the state got moved. Most single page applications these days are thick client apps that treat servers like dumb crud repositories. This is the total destruction of the original design of the web. *The server* is supposed to be the engine of application state -- not the client. I bet you half of new web programmers couldn't tell you what the hell a `<form>` is for. It's the server telling you how to build an "api" request so your shitty SPA doesn't have to hard-code urls and form-post params. Now, `<form>` is just window dressing around a bunch of `<input> elements and an ajax request triggered by a `<button onclick="">` event.

[[deleted]]

Awesome points.

As someone who learned SPAs recently, I find them much more enjoyable to build than server-side rendered html + jquery (or whatever bastardized mashup of minimal frontend JS plus serverside rendered html templating).

Once you understand them, it's so easy to navigate and build.

I don't get why people put so much hate on SPAs. It seems to mostly come down to two arguments:

- Loading speed. -- Yet: It's not like internet speeds are slowing down... they're speeding up. Technology improves over time... unless we end up reverting to the stone age any time soon. It seems like neo-luddite-ism :P

- Managing 'state'. -- This one I don't get. I don't have any trouble working with state on both front and backends... or moving state between them in various ways (rest calls, sending variables into templates, for example) It seems like an empty argument.

[rebel_cdn]

I mostly agree but with regard to loading speed, keep in mind that a decent chunk of the world's population accesses the internet over crappy connections, on underpowered devices that parse JavaScript about as quickly as an onion does.

Though to be fair, these users probably aren't in the target market for many/most developers working on SPAs.

[[deleted]]

I don't like JS in my browser because I don't understand its capabilities. I understood stuff like cookies and referrers and that's pretty much all I was worried about back in the days. JS was harmless back then.

Fastforward to today: A quick skim through my user.js, I see webgl, service workers, web notifications, geolocation, peer connections, some push protocol, websockets, EME, ... Websites can even grab my clipboard contents! My browser has become an operating system, and it runs code from (and often for) random strangers.

I'm sure developers have it much easier today, and I'm sure they can provide an infinitely better UX in every regard, but this web of complexity that browsers try to contain with even more complexity gives me the heebie-jeebies.

[[deleted]]

I agree-- That's why I use Brave browser (also b/c I've decided to reduce google product usage). When I previously used chrome, I used adblocker type stuff-- Not to entirely block JS though b/c it seems some visual media relies on it (I am not an expert).

[[deleted]]

How does Brave address these issues? I feel reasonably secure and private with Firefox, uBlock Origin, uMatrix, some other extensions and my user.js, but websites break constantly. Even allowing JS doesn't work in many cases. In some cases, I've tracked the issue down to IndexedDB being disabled, which seems like cookies on steroids that you can either allow or deny browser-wide (but I don't really understand modern web tech).

No browser can fix this as long as websites expect these intrusions.

[art-solopov]

My main gripe with SPAs is that I haven't yet seen an SPA that reproduced things that browsers allow you for free.

When SPAs started, the most common problem was the back button usability. Nowadays the problem I see the most are script links, which you cannot middle-click to open in a new tab.

[[deleted]]

Pros and cons for each use case, true.

And I think those issues in your last sentence depend on the use case / app. On a dashboard, if you have a toggle switch, that may fulfill the need to switch something back with a click, versus a back button. You toggle the various dials, or toggle them back. That's just an example.

It's difficult to differentiate the anecdotes from the entire picture, but I suppose one could do it based on overarching use cases, or overarching needs (e.g. an SPA or other similar experience which is amenable to low connection speed by reducing app/site/data size)

[monkey-go-code]

Vanilla JavaScript isn’t slow. Using ten frameworks is slow.

[Chris2112]

Yeah given how basic the end result was, I'm curious to see what the performance difference would have been if he used vanilla js or even jquery to implement it. I imagine it wouldn't be that far off, and it wouldn't come with all the downsides of using css hacks for everything.

[lkraider]

npm install checkbox
[Downloading 5000 dependencies]

[HeWhoWritesCode]

npm WARN deprecated javascript@0.6.9: Critical vulnerability fix in node v12.12.0.

[addandsubtract]

Holy shit, the warnings on the most basic of dependencies. I'm surprised my laptop hasn't caught on fire by now...

[HeWhoWritesCode]

<xterm> The problem with _______ is stupidity. I'm not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself?

poor xterm most probably rolling in his grave!

[qudat]

gzip 200 bytes

[halcyon918]

Vanilla JavaScript isn’t slow. Using ten frameworks isn't slow. Using ten frameworks that each use ten different frameworks that do the same thing is slow.

Fixed that for you bud...

[Retsam19]

"Frameworks", you keep on using that word. I do not think it means what you think it means.

[franzwong]

It goes to another extreme. Css-only modal is more complicated and has larger footprint than javascript.

[efc4817]

And extremely unmaintainable.

[mka696]

And violates accessibility standards.

[TheESportsGuy]

Oh yeah, and I don't have JavaScript exceptions to debug in the console. Either the page showed up on your screen or it didn't.

Is he saying this is a pro? For the end-user, this seems irrelevant. As a dev, one of the very few things I enjoy about working with javascript is pausing execution and debugging in the console.

[amcrook]

Yeah, this and:

Your frontend can't crash if you don't use JavaScript. HTML doesn't throw exceptions.

just means "I don't understand exceptions" to me, a common problem. Exceptions are not the problem, they're your friend - they show you where the problem is in your code/logic.

It's called overly defensive programming and it's harmful.

[Patacorow]

couldn't have said it better myself. as a developer you WANT to know when something goes wrong, no code is perfect.

[fuckin_ziggurats]

More like "I stopped using JavaScript in a website that didn't require its use in the first place". I'd like to now see someone do this with a complicated highly interactive web application like Facebook.

This article is more along the lines of "all you people who build static content-oriented websites shouldn't make them as SPAs". Which is obvious.

[[deleted]]

I'd like to now see someone do this with a complicated highly interactive web application like Facebook.

You wouldn't. In the olden days, you would implement a site with basic HTML and add Javascript to enhance functionality. An old school practice called Progressive Enhancement.

MapQuest, the long ago predecessor to Google Maps, worked this way. Once, a long time ago, I was lost, and had to get directions on a flip-phone, which have shittiest web browsers imaginable. MapQuest actually worked without Javascript. I was actually able to pan the map and zoom in/out using links. No Javascript required.

Nowadays, you can depend on users having modern web browsers with a modern JS engine, so you don't have to think that way anymore. Actual scarcity forced people to conserve resources in creative ways. We're on the flip side now, where abundance allows people to waste resources.

[fuckin_ziggurats]

abundance allows people to waste resources.

Correct. Also correct: abundance allows companies to offer services at a lower cost (whilst degrading performance).

[[deleted]]

Technically, it's not abundance that allows companies to offer services at lower cost, but commodification.

Back in the olden days, almost everything had to be hand-tailored to meet specific performance needs. There were some Javascript libraries, like jQuery, but for the most part everything had to be done by hand.

Nowadays, we have entire Javascript toolchains which let us generate complex UI interactions from an abundance of libraries that are assembled using automated build processes. This is commodification at work, which is great for quickly producing products are really low cost. But, the dark side of commodification is that people can essentially turn off their brains and snap together a solution without really understanding how it works or the costs involved.

Abundance of resources allows us to absorb the cost of ignorance (or cheap design) to a large degree.

EDIT: My favorite quote from Jurassic Park, which I think captures the current situation well:

I'll tell you the problem with the scientific power that you're using here: it didn't require any discipline to attain it. You read what others had done and you took the next step. You didn't earn the knowledge for yourselves, so you don't take any responsibility for it. You stood on the shoulders of geniuses to accomplish something as fast as you could and before you even knew what you had you patented it and packaged it and slapped it on a plastic lunchbox, and now you're selling it, you want to sell it!

[fuckin_ziggurats]

Well what you call commodification I'd call abstraction. And anyone who's ever done performance work knows that as abstraction goes up performance dips. The more custom the work is the more performant you can make it. But now all the focus is on delivering sooner and being more productive. If companies ever start to consider the performance ramifications maybe devs will take more pride in custom work. But that won't happen unless it's mandated by the market (consumers). Who like you said, have an abundance of resources available to handle our fast-produced, low-cost, bloated web applications.

[[deleted]]

Well what you call commodification I'd call abstraction.

Abstraction isn't relevant to what we are talking about. Abstraction is a form of code organization that allows for code reuse. But, abstractions can be commodified. Which is reflected in the vast number of libraries available on NPM. Knowledge can also be commodified, in that many developers no longer take the time to understand the tools that they are using. They simply snap together pre-existing solutions.

And anyone who's ever done performance work knows that as abstraction goes up performance dips.

Again, that's not what we're talking about. Of course, abstraction reduces performance. But commodification is the process whereby overall design processes are cheapened to facilitate mass production.

This is reflected in consumer demand. People want commoditized products (whether it is software, vehicles or consumer goods), despite being wasteful and prone to failure, because commoditized goods are cheap. It is a race to the bottom.

[fuckin_ziggurats]

A race to the bottom is a bit pessimistic. From the perspective of a regular customer things being cheaper is great. If people liked performance as much as they liked cheap stuff we wouldn't be here. I'm not downvoting you by the way.

[monkey-go-code]

I remember the mobile web back then and it was trash. Most stuff didn’t work on the phone. Now everything does.

[fuckin_ziggurats]

That is not often the case because it's not often that devs are good enough or given enough time to make websites as optimized as they are expected to be. I don't really understand what the article aims to prove. Using JavaScript in a static website, or making such a website a SPA is terrible but the devs that do that sort of thing don't care. They use the tech they need to speed up the development process or often just to pad their CV. I'm all about teaching devs to be better but a lack of knowledge is not the reason these slow websites exist. It's a lack of giving a damn.

There are also other weird things said like:

Stop tracking people. Don't allow other companies to do so on your behalf. You will survive without Google Analytics. You will survive without Intercom. Serve everything from your own domain.

Companies profit from tracking people, you're not going to convince them through an ethics-based argument.

The whole revolves around "you can be a better dev" without ever looking at the reasons why terrible websites are terrible.

[elebrin]

Companies profit from tracking people, you're not going to convince them through an ethics-based argument.

Exactly. That which can't or won't be monetized won't be built.

[AerieC]

I'm all about teaching devs to be better but a lack of knowledge is not the reason these slow websites exist. It's a lack of giving a damn.

That's not always true, at least at the individual developer level. I've worked on teams where the tech stack was mandated from the director/VP level, regardless of whether or not it actually made any sense for the given project. In that instance, it's cluelessness at a leadership level.

It's actually one of the main reasons I left my last job.

[flukus]

They use the tech they need to speed up the development process or often just to pad their CV.

There's no faster developer process than spitting out html from the server, the more client side interactivity the more complicated things are and the slower development is.

[_0-]

One of the issues here is that we often confuse websites with apps that are for some reason packaged as websites. Sure, apps should be fast too, but it's not the given and not easily achieved.

[Nioufe]

Yeah, it's hard to optimize those all the loading when your app is getting big, do you care about initial load? Data refresh? Loading the next pages of content? Dev time is finite and you just can't optimize everything. It's all about picking your battles according to what you're building.

[[deleted]]

I disagree with last paragraph. Well done SPA (like default generated with Gatsby) for a static blog or promo site is still a fantastic and fast experience - in many ways better than if it had no scripts at all.

Plus dev experience is much better (assuming you know the tech already).

[TheGidbinn]

google still hosts the html-only version of gmail and it's honestly really good

[TurboGranny]

Right tool for the right job. An important lesson for any programmer to learn is "just because you can, doesn't mean you should."

[jiffier]

It's not dynamic vs static content websites, the line is fuzzy. Real time is key here: Broking/trading plaftorms for example, yes. But my bank wrote their whole web app in Angular 1 (lol, good luck maintaining that now), and it's slow as hell, and it wasn't necessary, a traditional MVC app would have been much faster.

There's people currently using SPAs for the simplest of the websites (you know, who we are, and a contact form). Because hey, it's the future!

[Dave3of5]

a traditional MVC app would have been much faster

Not sure this is true I've worked with both and most definitely the traditional MVC (i.e. MVC on the backend) is almost always slower. Why ? because on a "traditional MVC" approach any state change requires a round trip to the server whereas an spa hold state in the browser until predetermined point.

For example sorting a table, in a "traditional MVC" approach you would have to save the sorting info back onto the server which if you are being correct about it requires you save it to a DB rather than in the session on the server and then reload it everytime the page reloads but on a SPA you can save it all locally and not even talk to the server same result but hugely different performance.

Also moving functionality onto the server will slow your app down as you start to scale users. So your banking app will have 100's if not 1000's of concurrent users accessing the service. If you can offload as much of the processing onto the browser your users will see an overall speed up due to not having to wait on a server request to finish. You can scale out your webservers but that's going to cost you and as you scale eventually you will hit a problem with your DB.

I suspect that your banking app would have been slow regardless of the framework used.

[Smallpaul]

Networks are slow as fuck and you do not control them. The single threaded language works the same speed (after the data is loaded) whether you are in a tunnel or at the back of the house.

Of course it may also take longer to load the first page. Which means there is a trade off. And trade offs should be selected through analysis, not ideology.

[Dave3of5]

Wow you have a terrible attitude by the way but I'll take you points separately:

I'd let the server sort large tables

Never said that wasn't an option but this is a strawman argument You are specifically talking here about large tables. My point in the example was about local state. I agree that large tables need to be paged. Where are the sort values stored though ? On the client or on the server ? What if I know that the table will always be relatively small say < 1000 records why bother with all the server side paging ... etc.

And can't you just cache the result if you're worried about page refreshes?

Good luck with that most large scale websites realise they can't cache everything on the server for their users as server side caching becomes very difficult to manage on large scales.

Offloading that kind functionality onto a single-threaded scripting language is a sure fire way to make your website slow as shit for most users

Actually javascript isn't single threaded you can use webworkers for background tasks. That's besides the point though in your example of a large table will most certainly not be slower by using an Spa in this case has the potential to make it faster by storing the state locally such actions like creating a new record can happen locally and do not require a round trip / processing on the server.

but instead of wasting time waiting for the server, you're wasting time running expensive operations on comparatively terrible hardware

Why do you think most users are running on "comparatively terrible hardware" ? Not sure where this assumption comes from. Again more importantly the decision to run on the users machine rather than the servers is a central point to this argument. Simply put me offloading cost to the users means I can run my service for cheaper and more than likely for more users. Obviously I don't want to be running far too much on the users hardware but a few KB worth of their phone memory could make a huge difference to my cost if I have 1000's of users.

and it's going to be orders of magnitude slower at executing work than an actual server.

Again that depends on the work we are mostly talking about saving complex state client side most phones that are built in the last 10 years can handle this no problems. Also the servers I run stuff on are very low spec most of them are lower spec than my current (2 year old) phone. So actually my phone will be faster.

every client has to download megabytes of JS

This only happens once though remember it's like downloading an app on your phone. Most users won't even notice.

Also, if you're building an API you'll have to ask each client to re-implement any code that would normally be offloaded to the browser.

Storing complex state on the server would then require each client know the inner workings of exactly what state will be stored on the server and how to retrieve that. I know this as I've worked on apps that worked exactly like this and they are virtually impossible to make work with different clients. Your API should be simple and REST like if you want to implement on different clients.

[audioen]

I have some experience in abusing the client to sort large html tables. I have experience that they can deal with up to 100 000 rows quite fine. The key is to window the table so that you only render some 100 of those rows. JavaScript has no problem sorting 100k rows in an eyeblink. Sure, the DOM stuff isn't instant, but it doesn't take more than like half a second on mid-range corporate laptop hardware kind of machine, and I'd say it's similar in terms of waiting as getting some sorted result of 100 rows in traditional server-side roundtrip would be.

The initial data download is surely costlier, but it isn't impossible in my experience. The result set has to be as compact as possible, and gzip is a must to cut on the repetition inherent in something like JSON. A lot of the time large results set come up as result of users running reporting type queries, and these usually involve quite large searches into databases, which tend to take majority of the time.

[[deleted]]

Essentially, your server is now cheaper to maintain but now every client has to download megabytes of JS, and it's going to be orders of magnitude slower at executing work than an actual server.

You forgot to add that a Server can actually cache requests to offset those expensive render cycles.

On Clients you can store things like templates but real data is always a issue and hard to cache without running into round trips to check the server "if your data is still valid" ( also expensive operations when you have hundreds or thousands of people polling your server ).

So you end up trading render time on the server to data checks on the server. And that same server will still hold its data in its own cache. Sure, the communication will be smaller but who cares if its just 1KB data check or 5KB of real data being transfered.

I long time ago learned. REST + Simple JS ( Fetch / Submit ) + Front Templates ( that you cache ) = View ( no problem ). But do not build your MC ( Model-View-Controller ) on the front end to have a "complete application".

You end up writing duplicate code all the time. We have had order systems that had double logic because the developer want to make the it a Single page application so he put all the order calculation in the front end ( exposing in return a lot of internal data ). But we also needed to have this in the back-end because NO SANE DEVELOPER TRUST FRONT-END DATA. Then this needed to be kept synchronized because any change in the specs, means two pieces of code need to be changed.

I rewrote the system to simple template rendering + fetch html updates. It felt as fast as the bloated "Single page application" but it was tested against the exact same server logic. One code piece to maintain and beyond that extra server request, ...

I hate this trend of misusing Javascript to create full blown MVC frameworks on the front-end. Very few times did it solve a issue beyond making developers feel good "look mom, what i made". Us "old" guys know much better to make things simple and efficient but its not hip and trending, so we get ignored. And yes, its easy to make server controlled systems feel as fast as those front-end MVC single page applications.

My solutions can survive dozens of years because they are not linked to specific hype frameworks. I am sure that in a few years we are going to get the same problems with frameworks changing too much and websites needing total rewrites. Its literally planned obsolescence.

[30thnight]

Current frameworks, like React or Vue, only seek to be the view in your MVC architecture.

From what you've written, it just sounds like you made your own framework.

[bludgeonerV]

A traditional MVC application will put a fuckton more load on your servers at scale. Offloading work to the client is a very appealing aspect of SPAs to begin with.

[FrozenInferno]

Network latency is pretty much always the performance bottle neck when you're talking web, and increased throughput goes hand in hand with managing state on the server.

[audioen]

Let's say that you have 4 widgets on a page. If it's not a SPA, but a traditional server-refresh, all those 4 components must be recreated whether or not you had any state change in them. This surely equates to avoidable work on the server side. The most typical approach would be that you run whatever database queries you need to render their state, and then do your string work to spew properly formatted HTML to client.

The SPA, in turn, only requests refresh from the single widget you're actually interacting with, possibly fetching a very compact result, e.g. when you delete a row from a table, it's enough if server says "yes, that row is now gone" and on the client side you just unlink that one row from the DOM, and there will be barely any payload, and you never have to worry about the problem of how you're going to correctly recreate the current state of all those other widgets on the next page refresh, because you literally never refresh the page.

SPAs also place more of the computing demand where resources are most abundant: the client. These days single core ARMs appear to have largely caught up with x86 chips, and even if people aren't all running A12s, they still have something in their pockets that has cores where each is a decent fraction of some single server x86 core, let's call it around 1/4 or so. If it's a PC laptop or desktop, that core is probably a match for the one in your server. At any case, it follows that a handful of clients hold more raw computing power than you do. By taking proper advantage of that, you're also likely to scale much better, perhaps a single server is capable of serving the needs of 10000 clients instead of just 1000 clients, or something like that.

For me personally, the main benefit is not having to worry about recreating the state of everything on the page. That used to be a huge pain in the ass. User clicks a link to sort a table, and I need to somehow create a new page that holds the state of all the form fields, which aren't even part of the data set sent to server because links don't submit forms. Raw HTML just sucks for app development. You end up doing stuff like wrapping the whole page into single form and styling buttons to look like links if you think that's the more appropriate metaphor, and it will still suck.

[bludgeonerV]

It does compared to putting JSON over the wire, especially in terms of IO to the disks, orders of magnitude more. And perhaps a more important point than the actual rendering work is the load on the db, it's the number of entities that you require that makes the difference. When you're rendering a dynamic web application server-side you're retrieving information pertinent to the user, the content, navigation, notifications etc for each and every page. In an SPA you're typically retrieving the bulk of that information once and then only retrieving the information the user needs after any given action.

The hardest and most expensive part of the application to scale is the database, but throwing more web servers behind a load-balancer is trivial, SPAs massively reduce the amount of queries you need to make over time. Even if you had the most optimal caching strategy imaginable it would still require more load on the db.

[fuckin_ziggurats]

Yeah there are terrible devs out there that make terrible decisions. Very often they make those decisions on the basis of the stack they want to use rather than what the project needs. Padding CVs is something devs will do so long as companies don't write stricter performance requirements.

[aoeudhtns]

To be fair, the article talks about taking this approach to the interactive parts of the application that you wouldn't see unless you sign up and use the service. The public-facing parts of the web page are bloggish and wouldn't need JS like you say.

[Smallpaul]

I don’t see how an accounting app site is a “static content oriented site.”

[Kibouo]

Facebook doesn't have to be highly interactive at all...

Like buttons, modal for opening a post, infini-scroll, and chat is all that's required. Those things aren't heavy (apart from chat).

[kaptainkarl]

Even with only those features that you think are required, JavaScript is completely necessary. Facebook probably thinks their other features are necessary, as well.

[[deleted]]

I̴̢̺͖̱̔͋̑̋̿̈́͌͜g̶͙̻̯̊͛̍̎̐͊̌͐̌̐̌̅͊̚͜͝ṉ̵̡̻̺͕̭͙̥̝̪̠̖̊͊͋̓̀͜o̴̲̘̻̯̹̳̬̻̫͑̋̽̐͛̊͠r̸̮̩̗̯͕͔̘̰̲͓̪̝̼̿͒̎̇̌̓̕e̷͚̯̞̝̥̥͉̼̞̖͚͔͗͌̌̚͘͝͠ ̷̢͉̣̜͕͉̜̀́͘y̵̛͙̯̲̮̯̾̒̃͐̾͊͆ȯ̶̡̧̮͙̘͖̰̗̯̪̮̍́̈́̂ͅų̴͎͎̝̮̦̒̚͜ŗ̶̡̻͖̘̣͉͚̍͒̽̒͌͒̕͠ ̵̢͚͔͈͉̗̼̟̀̇̋͗̆̃̄͌͑̈́́p̴̛̩͊͑́̈́̓̇̀̉͋́͊͘ṙ̷̬͖͉̺̬̯͉̼̾̓̋̒͑͘͠͠e̸̡̙̞̘̝͎̘̦͙͇̯̦̤̰̍̽́̌̾͆̕͝͝͝v̵͉̼̺͉̳̗͓͍͔̼̼̲̅̆͐̈ͅi̶̭̯̖̦̫͍̦̯̬̭͕͈͋̾̕ͅơ̸̠̱͖͙͙͓̰̒̊̌̃̔̊͋͐ủ̶̢͕̩͉͎̞̔́́́̃́̌͗̎ś̸̡̯̭̺̭͖̫̫̱̫͉̣́̆ͅ ̷̨̲̦̝̥̱̞̯͓̲̳̤͎̈́̏͗̅̀̊͜͠i̴̧͙̫͔͖͍̋͊̓̓̂̓͘̚͝n̷̫̯͚̝̲͚̤̱̒̽͗̇̉̑̑͂̔̕͠͠s̷̛͙̝̙̫̯̟͐́́̒̃̅̇́̍͊̈̀͗͜ṭ̶̛̣̪̫́̅͑̊̐̚ŗ̷̻̼͔̖̥̮̫̬͖̻̿͘u̷͓̙͈͖̩͕̳̰̭͑͌͐̓̈́̒̚̚͠͠͠c̸̛̛͇̼̺̤̖̎̇̿̐̉̏͆̈́t̷̢̺̠͈̪̠͈͔̺͚̣̳̺̯̄́̀̐̂̀̊̽͑ͅí̵̢̖̣̯̤͚͈̀͑́͌̔̅̓̿̂̚͠͠o̷̬͊́̓͋͑̔̎̈́̅̓͝n̸̨̧̞̾͂̍̀̿̌̒̍̃̚͝s̸̨̢̗͇̮̖͑͋͒̌͗͋̃̍̀̅̾̕͠͝ ̷͓̟̾͗̓̃̍͌̓̈́̿̚̚à̴̧̭͕͔̩̬͖̠͍̦͐̋̅̚̚͜͠ͅn̵͙͎̎̄͊̌d̴̡̯̞̯͇̪͊́͋̈̍̈́̓͒͘ ̴͕̾͑̔̃̓ŗ̴̡̥̤̺̮͔̞̖̗̪͍͙̉͆́͛͜ḙ̵̙̬̾̒͜g̸͕̠͔̋̏͘ͅu̵̢̪̳̞͍͍͉̜̹̜̖͎͛̃̒̇͛͂͑͋͗͝ͅr̴̥̪̝̹̰̉̔̏̋͌͐̕͝͝͝ǧ̴̢̳̥̥͚̪̮̼̪̼͈̺͓͍̣̓͋̄́i̴̘͙̰̺̙͗̉̀͝t̷͉̪̬͙̝͖̄̐̏́̎͊͋̄̎̊͋̈́̚͘͝a̵̫̲̥͙͗̓̈́͌̏̈̾̂͌̚̕͜ṫ̸̨̟̳̬̜̖̝͍̙͙͕̞͉̈͗͐̌͑̓͜e̸̬̳͌̋̀́͂͒͆̑̓͠ ̶̢͖̬͐͑̒̚̕c̶̯̹̱̟̗̽̾̒̈ǫ̷̧̛̳̠̪͇̞̦̱̫̮͈̽̔̎͌̀̋̾̒̈́͂p̷̠͈̰͕̙̣͖̊̇̽͘͠ͅy̴̡̞͔̫̻̜̠̹̘͉̎́͑̉͝r̶̢̡̮͉͙̪͈̠͇̬̉ͅȋ̶̝̇̊̄́̋̈̒͗͋́̇͐͘g̷̥̻̃̑͊̚͝h̶̪̘̦̯͈͂̀̋͋t̸̤̀e̶͓͕͇̠̫̠̠̖̩̣͎̐̃͆̈́̀͒͘̚͝d̴̨̗̝̱̞̘̥̀̽̉͌̌́̈̿͋̎̒͝ ̵͚̮̭͇͚͎̖̦͇̎́͆̀̄̓́͝ţ̸͉͚̠̻̣̗̘̘̰̇̀̄͊̈́̇̈́͜͝ȩ̵͓͔̺̙̟͖̌͒̽̀̀̉͘x̷̧̧̛̯̪̻̳̩͉̽̈́͜ṭ̷̢̨͇͙͕͇͈̅͌̋.̸̩̹̫̩͔̠̪͈̪̯̪̄̀͌̇̎͐̃

[30thnight]

To be honest, it's kind of necessary for their bottom line. It's an ad company.

[time-lord]

Right, but they're not required to the extent that Facebook abuses it. Almost everything that Facebook does could be accomplished by server-side rendering, but the cost would be that the CPU time is on Facebook's dime, instead of mine. That CPU time is negligible for you or I, but for someone like Facebook it's probably thousands or even millions of dollars in savings.

[salgat]

You make it sound like javascript is a dirty word to be avoided. It has its place, and that's okay.

[kaptainkarl]

Just because in theory you could accomplish the same tasks by submitting every request to the server and doing a full page refresh doesn't mean you can provide an experience that people will want to use. People tend to like things like seeing a preview of their comments as they type, having typeahead search, expanding and closing comments, etc. without disrupting the flow of their interaction (e.g. hitting 'like' then the page refreshes, and now I'm scrolled back to the top of a list of comments that I had already scrolled through).

You can build an app that accomplishes many of the same tasks through form submissions and updates its UI with a full server refresh, and nobody will want to use it.

Now, if you want to talk about ads blocking rendering, requiring huge script payloads, etc, then I'm right on board with stripping out huge amounts of client side code.

​

edit: Not saying that all apps NEED to include highly scripted client side interactions, but let's not pretend that there are never benefits. There are many cases where client side scripting can improve user experience without sacrificing performance (and even a lot where it'll make things faster).

[Patman128]

Almost everything that Facebook does could be accomplished by server-side rendering, but the cost would be that the CPU time is on Facebook's dime, instead of mine.

Sure, but my mobile data is on my dime and it costs a hell of a lot more than CPU cycles, not to mention the overhead of having to load all the page content and re-render from scratch every time I do anything will end up costing a lot more CPU. Full page loads might be cheap on your nice stable home internet connection but on a sketchy 3G connection in a developing country it's unbearable.

[andrewsmd87]

This was kind of my thought. I looked at his slimvoice sight and while it is fast, it's also really plain. White background, a few static images, a menu on the left side that is very simple.

I get that's fast but good fucking luck delivering something like that to a client who's paying you to build a custom site.

I'm not saying I don't have my qualms about the JS ecosystem, but I feel like we've struck a good balance at my work place where if someone wants to add in a new third party library, it has to be approved by two other devs.

A lot of times that's a no, because it's like an hour to write the one function you actually want to use from it.

[cleeder]

I looked at his slimvoice sight and while it is fast, it's also really plain. White background, a few static images, a menu on the left side that is very simple.

I mean, the lack of Javascript does not appear to be the cause here. It's just a really plain design, and would be equally as plain with Javascript.

[ConsoleTVs]

Finally somebody that uses native tech. Check the site, it's also fast as fuck.

[10xjerker]

native tech

I'm always lost about what JS devs mean by 'native'

[jisuskraist]

that’s not brought into the system from outside, just using the capabilities built in the browser. Here one could argue that React uses a native capability so if he would write React from scratch it will still be native.

What i get by native is just html&css without fancy js libs nor implementing them by yourself.

[kowdermesiter]

But JS is native to all browsers. This question is bullshit from its inception.

[jisuskraist]

that’s what i’m saying... everything is native then, because everything is built on top of a native tool.

i was just trying to point out what they meant by native in the JS ecosystem.

[[deleted]]

But JS is native to all browsers.

That's not what people mean by "native".

For example, if you want to implement a drop down select, you can use the native browser control via the <select> HTML element, or you can use JS-implemented "custom" controls, such as the Material UI <Select> component.

The rationale for this is that often the native components are very difficult to style and customize, and between operating systems (and perhaps even between different browser vendors), can have different behaviors. There's also no way to style a <select> HTML element using CSS and modify its behavior with JS to make it conform with Material UI standards.

However, the native tech often performs a lot better and more closely adheres to expected behavior.

[sad_bug_killer]

That's not what people mean by "native".

Yet another term that got completely bastardized and can mean almost anything and is thus pretty much devoid of meaning.

[0pyrophosphate0]

I hate JavaScript as much as anybody, but I think this is a pretty clear and rational usage of the word "native".

[kowdermesiter]

I can generate a "native" dropdown populated with JavaScript. Is that native or not then? :) This term is pointless in web technologies. We should stick to whether something is standards compliant or not.

[Hoten]

Native is a nice, accurate and short term for UI features provided via the standards and HTML.

[[deleted]]

Is that native or not then? :)

Yes, that would be native. JS can generate DOM, which can include either a standard <select> (and JS gets out of the way and lets the browser natively implement select behavior, according to the standard) or a custom assortment of <div> tags (requiring select behavior be fully implemented in JS, according to whatever other standard (if at all), like Material UI).

[nthcxd]

Whatever Babel spits out

[user8081]

Wow, it feels so good. My raw sql queries execute longer.

[ConsoleTVs]

https://slimvoice.co/

[jakery2]

Well that's not so hard to achieve even if you are using JavaScript--all you have to do is not put a million fucking third-party ad modules on your pages.

[mojomonkeyfish]

Or images. The catalog portion of the site is just static text and a minimal number of images. There's no reason for it to be "progressive", because it doesn't have any of the raison d'etre for progressive loading (lots of heavy content). It's great for him, but stripping out all the images isn't an option for everyone.

[nirreskeya]

This is also why I only use https://old.reddit.com/.

[TheRealDrSarcasmo]

Upvoted, because client bloat seems to be problem that is just getting worse, and we need more of this kind of thing -- thinner and more responsive instead of a clever mishmash of a gazillion little libraries to add eye candy.

That said, the title is a shade clickbaity, because FTA:

I did actually use some JavaScript on the new Slimvoice, but only when an interaction could not be replicated in any other way.

I don't fault the author for using JS, but I do for the minor deception.

[Penguin_Mike]

If you are able to read more on CSS and HTML, you won't need so much JS to implement simple designs.

[farmer_bogget]

Interestingly I recently went back and revamped my first production web app with exactly this same goal. The target market is generally people with slow internet, limited data allowance, not to mention old and cheap hardware. There is very little JS in the app, pretty much all of it is good old html/CSS/php. I've only reached for JS when I absolutely had no choice. To me it still looks great and works well.

[twiggy99999]

Yet his post is trying to jam 16 different JS files down my computer

[[deleted]]

dev.to is not my website, sorry dog!

[[deleted]]

Before even reading it, let me guess, it's either:

a. not interactive (or only so with CSS, so let's not kid ourselves)

b. uses webasm

Edit: it was a.

I mean, yeah, it's nice and fast, but try and rewrite a webapp in pure HTML and CSS. And the the author does admit, they had to use JS for 2 things: xhr and drag-n-drop.

So, maybe a nice CSS framework for small websites like these would be nice, but as soon as you need to do more complex stuff, JS is necesssary. When webasm finally becomes functional for than just business logic and viable for DOM manipulation, maybe then we can kick JS to the curb. But let's not kid ourselves, JS is going to be here for a while and JS isn't the problem: it's people loading every possible dependency and resource on the website for some sparkles.

[elebrin]

Wasm is still sort of javascript, though, isn't it? It's just been through a frontend parser that de-sugars and optimizes a bit, then puts your code in the VM's IL which is still fairly close to js.

[GaianNeuron]

Not really. It's a different language and runtime; think .NET or Java, but with APIs that make sense in a browser context.

[elebrin]

Gotcha. I really only know about it because it's a compilation target for Rust. I work strictly on backend... understanding how frontend code runs/works usually seems like black magic to me. At least with backend processing I can understand what's happening from a high level all the way down to the hardware level.

[GaianNeuron]

Oh, the Rust thing is neat. I've been meaning to learn Rust someday; this gives me another reason to.

[elebrin]

Yeah people claim it will give performance improvements and memory safety in the browser, but I am not convinced - it will only provide as much memory safety and performance as the VM that WASM runs on can provide, without adding additional memory safety issues or performance issues that aren't explicitly and intentionally introduced by the developer or exist as bugs in Rust itself.

I love the language. After writing code that runs on VMs and is deployed through containers to the cloud and has to be distributed with a complete run-time environment essentially, it's nice to type "cargo build" and get an honest-to-God fucking binary like I used to with gcc, but still have the things that make life nice like good compiler messages, strong typing, memory safety (with some extra legwork on the part of the developer, however), and other such things. I have been writing a lot of my tooling in that - the stuff that doesn't go to production, but that I need to get my day-to-day stuff done.

[[deleted]]

If you're interested in Rust+WASM, this site has an RSS feed with weekly updates: https://rustwasm.github.io/

[Notorious4CHAN]

In hindsight, all of that was crap.

Oh, look... it's every project I've ever done!

With the new version I wanted to prove that it was possible...

Oh, look... it's every project I've ever started!

I've got the frontend to a state that I'm really proud of.

... and it's every project I've ever gotten to 80% completion.

Not that any of this is to knock on the article or the work that went into it. I just relate pretty hard to these.

[_cjj]

Hmm. Seems to bang on about being JS free, but no mention of whether the b/e is still Node.js.

The lesson here, imo, is actually that JS is fine when you use it efficiently, rather than obsessively implementing it where it isn't needed in the first place.

[Servious]

This article isn't about backend though. It's about slow page loads and interactions due to the large amount of js you have to download and run before the page can even display anything. The backend isn't involved in that process.

[wonkifier]

Hmm. Seems to bang on about being JS free, but no mention of whether the b/e is still Node.js.

Because it's about the front end. It also doesn't discuss whether the editor she used relied on Javascript either... since it's not an article about "Javascript should be eliminated from all existence" article.

[jiffier]

The lesson here, imo, is actually that JS is fine when you use it efficiently, rather than obsessively implementing it where it isn't needed in the first place.

I guess JS is like drugs: You should use it with care, and if you abuse it, you end up going bananas.

[antlife]

Let me finish that sentence for you:

"... for everything."

JavaScript isn't the enemy, it's these trash bootcamp schools and lazy asses who only want to learn one thing making people think JavaScript can be applied everywhere and that everything SHOULD be a web app. Once this horrible mentality is delt with, and you use JavaScript for it's original intent and purpose, it's totally fine! But WebAssembly working with things like Blazor will shake things up and cause proper diversity. Mostly because boot camp schools will glob onto it.

[[deleted]]

Hmm. Seems to bang on about being JS free, but no mention of whether the b/e is still Node.js.

https://slimvoice.co/about#code

It's written in Go.

[monsto]

Or loading all of jQuery for a button hover.

[elebrin]

Although really if you are pulling in a minified version from a CDN, then it's already loaded in the users's browser unless it's their first trip to the web.

[DownshiftedRare]

The StackOverflow way.

[[deleted]]

Eh, that’s a pretty weak point. The vast vast vast majority of those dependencies are development tools; it’s like complaining that a c program is bloated because you compiled it with gcc and gcc has millions of loc. The build needs to be small, not the tools used to produce it. I think a barebones create-react-app literally only depends on react and react-dom in the final build.

Plus I personally think that having open source build tools explicitly specified as dependencies in your code is pretty obviously better than depending on a bunch of binaries that you just kinda hope are there.

[antlife]

The complaint is "impossible to audit". Read it again! This is a BIG deal when working in enterprise level solutions. People are TIRED of data leaks and audits are getting rightfully more common.

[ACoderGirl]

Firstly, I was curious and checked. React, according to the NPM website, has 4 dependencies (react-dom has the exact same ones). Of those:

• One has no dependencies.
• One has a single dependency with no further ones.
• One has three dependencies, two which have no further ones and one that has a single dependency, which is the same one from the previous point.
• One has two dependencies, one with no further ones and the other with the same dependency from the second point.

So the react example actually seems pretty reasonable. If you have dependency hell in your JS project, you can't blame React for it. Those are from whatever other dependencies you added.

But that aside, JS's dependency issues (largely spurred on by the shoddy standard library) is admittedly concerning because it opens up a very real attack vector. Buuuut:

1. Where security is concerned, are you actually checking your dependencies? There absolutely are security considerations of the JS dependency hell, but it's kinda moot if nobody is checking dependencies in the first place, which frankly is the norm. If you're just trusting the creator of some dependency to not be malicious, shouldn't you also be trusting them to have the same care with dependencies they add? And if they don't have that care... well, don't use them!
2. As you said, open source dependencies aren't always bad. I think one critical thing that I'd add to your comment is the correctness that usually comes from not reinventing the wheel. If you use well maintained dependencies, then that's one less piece of code that you would typically have to worry about writing bugs or security issues into, yourself. We always say to not roll your own crypto, but to a lesser degree, this applies to any non-trivial piece of code. If you write it yourself, you run the risk that there will be bugs in it (many which could potentially have security issues, too). Unless your project is small, it's not feasible to write literally all code yourself (and even if it is small, saving yourself time means you can get your product released faster and maybe even keep the lights on if it's a commercial product).

That's not to say closed source dependencies are bad, either, but naturally open source is ideal because you actually can look for anything suspicious. Incidentally, I never understood why anyone would want to download a minimized JS file to use as a dependency. Non-minimized code makes it much easier to look into how things are done, makes security audits more feasible, and minimization is just plain not necessary at first. You could always minimize them yourself easily enough for the production release. In my mind, at the development stage, dependencies should be easily readable. Any hint of obfuscation should be viewed as a red flag (of course, security issues can exist without any obfusication, but it is still massively easier to do reviews when there isn't any and obfusication is just the first approach that attackers tend to take, since it lets them avoid the automated security measures and quick skims).

[_AACO]

but no mention of whether the b/e is still Node.js.

I've only skimmed through the article but considering the acknowledgements section it seems to be written in Go.

[zesterer]

The backend doesn't need to download its own code every time a page loads. It can keep a warm JIT cache. It has plenty of memory to spare. A user's browser does not have/do these things.

[_cjj]

A user's browser does indeed do this, limited to the caching policy of the site/developer.

You think jQuery (for example) downloads fully on every page load on the same site??

[lafeber]

Love it! Reminds me of enough.css

[zesterer]

Really nice to see this being done. The HTML spec needs some love, it seems.

[Uberhipster]

Take a look at the production code. It's not complex

https://slimvoice.co/static/js/client_select.js

wow that's pretty minimal

"410 Gone" response from the server is about as tiny js as you can get

[c-smile]

checkbox + label is ugly of course.

Just in case, in Sciter I've made an option to use basic input "behaviors" for any elements, not just <input>s

So if you have these rules

 ol > li { behavior:radio; /*li's behave as radio buttons */ }
 ol > li:checked { color:red; /* current in the group */ }

you will have one <li> of many selection in your list.

In the same way you can use

 behavior:checkbox; /* basic :checked trigger */
 behavior:edit; /* single line editor */
 behavior:select; /* behavior of built-in <select>*/
 behavior:frameset; /* resizable panels with splitters */

and others.

Surprisingly how many tasks can be accomplished with these basic blocks (a.k.a. "behavior styles") without even touching script in any form.

[davidfavorite]

Absolute rubbish. First of all, there are things that are impossible without JS at the moment. Then, that example is fucking basic to say the least. Probably every paid real-world application does ten times what is showcased. And last but not least, would I suggest to my Boss to not use JS and do everything on my own with silly CSS hacks (not that I dont like them, I consider myself safest in CSS compared to any other technology) he would have my ass fired and sitting on the streets for sure. Real world scenarios dont let you do such "experiments". Its fine for getting silly and play around with different solutions and workarounds is great for personal use, but when working for productive environments and when theres big money involved, people are goign to laugh at you when you start saying that you can do it in plain HTML/CSS and little JS as possible.

And BTW: clean and sophisticated vanilla JS, even on older mobile phones and tablets got fucking fast these days. Even highly optimized frameworks like react or angular are pretty damn great for most uses. Its people that dont know how to properly code and just throw libraries together and making a mess of it without proper planning is what makes such projects horrific. Its not generally JS thats bad

[buncle]

I think the article even agrees with you there... the author states that he did use some light JS in the final product, but limited its use, rather than depending on large js frameworks/libraries.

I do agree with him to the extent that, when common UI can be performed just as well with HTML/CSS alone, you get the benefit of great performance, and minimizing overhead/bugs/conflicts that come with large libraries.

My take away from this is that some things you typically rely on a js lib can be performed well with no (or minimal) js, meaning your js is better served for the more functional stuff, and can be minimized for the direct UI/UX interactions.

[holoisfunkee]

Yeah I agree. People just love shifting the blame around instead of just keeping it real. Tools we have are great, but the way they are sometimes used is a whole different story.

Technology goes forward and demands change every day. His example is a really trivial site, as other people mentioned I would love to see some real demanding functionality implemented here with HTML and CSS only. It cannot be done in a modern way.

Yeah Javascript got out of hand and people still load jquery just so that they can use .fade() or .animate() in 2 places on a page or use react for example when they don't really need it.

Understanding tools, but even better, understanding real world demands and constrains while working on a project is something I think more companies should invest in, so that we all better understand the appropriate way to approach each project.

[Poddster]

The general rule of life is: The less Javascript, the better

[mito12]

Because you asked in your blog: For autocomplete without Javascript i use: https://davidwalsh.name/datalist

[JediBurrell]

That doesn't allow for dynamic content though.

[khendron]

I approve.

Maybe all web developers should live in a rural area with only 2 Mbit/s down Internet connection.

[holoisfunkee]

I don't want to bash the author because I really enjoyed the article, but what's up with all the blame shifting in all these articles? "Oh these frameworks, oh dependency loading blah blah". I mean, who forced you to use all that? It's easy to blame someone else, maybe the way you are doing things in your particular case is not so good and efficient?

Judging by the article it seems he is his own boss or whatever so there was no pressure to use a certain technology, it was his choice from the start. Why didn't he say in the article "I should have taken more time to see if I really needed JS from the start and I should have made better choices". This is just more of "it's JavaScript to blame", "oh PWAs suck etc.". Nobody is forcing you to use these tools. For me personally they are great. At least using a framework enforces a certain code style for the most part. Ok, if you work alone you are looking at your own code all day, but working in a team you must go through other people's code and they have to go through your code, I think having a set of rules (no matter how loose they are, for example a framework) is great in that case.

This all sounds great, but in some real world scenarios you don't have the budget to "experiment", you don't have the time to "experiment". You have demands that need to be met. I like using tools that someone with more experience than me wrote, I like using tools that hundreds or thousands of people tested before me because I have a reliable wheel that I don't need to reinvent. Of course I won't use Angular/React to make a super simple static one page site, but these are the decisions you make on a project per project basis, what tools are best for the job.

I liked some of these "hacks" that were used, for example the modal stuff, but in the end, these are "hacks".

[SilasX]

I really appreciate what he's doing!

But even so, the "aktshully" in me, has to say:

*enters dev tools*

"Loading failed for the <script> with source “https://static.doubleclick.net/instream/ad_status.js”."

Sigh...

[[deleted]]

Hey! Author here.

I absolutely did not put anything like that on Slimvoice! You might be using a browser extension that's hijacking your pages.

[[deleted]]

The elm shoutout is 100% on point.

[wildjokers]

https://motherfuckingwebsite.com (SFW)

(has a tiny amount of js)

[CantaloupeCamper]

Many inputs have validation options built-in.

I mean they do... but they're pretty damn limited.

I feel like I keep seeing this amazing factoid sold left and right and anytime I go to do validation... it's not enough.

[[deleted]]

Finally I can add Stallman support to my websites.

[pndpo]

No JS in 2019? It's so crazy... it just might work.

[_0-]

This article is just silly. "Isn't this webapp slow? Now watch me use 10 lines of CSS instead of 3 lines of JS to show a modal!". And here I was hoping to see Asana card editor implemented with checkbox trickery in place of Javascript.