19 ms·

A JavaScript-Free Front End

484 points by bibyte 8y ago

asdfasdfdavid 8y ago
This is beautiful!
blue4 8y ago
wow this is excellent, <details>/<summary> are good tricks
- elhenrico 8y ago
  And contrary to the article, it is possible to change their style!
- technotarek 8y ago
  Except for the "works everywhere" suggestion... https://caniuse.com/#feat=details https://caniuse.com/#feat=details And here I thought Edge was a modern browser.
  - blunte 8y ago
    Given that Edge has less than 5% marketshare globally (depending on the source of the information), I would say that fretting over compatibility with it is not a priority. And given that MS is moving Edge to Chromium rendering engine, I assume this will solve the compat problem.
    - technotarek 8y ago
      5% can still be a decent number of users, and tends to trend even higher in certain segments (state and local government, smaller "old economy" businesses)
  - dictum 8y ago
    It's a basic DOM element — a block of content. Without native support, it's simply shown by default, instead of hidden by default, so nothing is broken, and even the default on non-supporting browsers can be changed with JS and CSS. If anything, this is the works everywheriest of things that "work everywhere" in post-2010 web development. Some other stuff actually breaks accessibility by default.
    - technotarek 8y ago
      Thx. Good to know. In that case, selective usage seems like good policy.
andrewfromx 8y ago
100 percent agree. Use as little JS as possible on front end. And then definitely use zero JS on backend.
- tracker1 8y ago
  Definitely...only use C on the backend, any other language is just a hack.
  - sixstringtheory 8y ago
    I get the snark, but Java, Rust, Erlang are all better options than an interpreted language for backends IMO
    - Scarbutt 8y ago
      nodejs and expressjs are pretty solid stable tools these days. And there is always typescript if you are into that.
    - tracker1 8y ago
      Define better... Scripted languages can be run without the need for a compilation step, if you're scaling horizontally anyway, you can do nearly as well with node, and node can handle 100k+ connections per core with minimalish memory overhead. Functions are first class, functional approaches are easy and flexible, and when you're just passing bytes to another system or database, JS/Node works well. As to interpreted languages, JS/V8 has probably seen more optimization than any other interpreted language. As to Java, you don't need a 400-500mb base image either. Rust takes much longer to develop against, as does erlang even if you're familiar with it. If you're parsing JSON into concrete objects, the overhead is often larger with compiled languages than interpreted, where JS just works. I can generally get stuff working in around 1/8 the time it takes for peers to use a compiled language to do the same. Go is probably a better option than the three you suggested, even then more often than not, I would choose node, just because of the flexibility I get with npm and the larger community. If I, in turn need to eek more performance, or have a process that requires more compute per request, then I'll often reach for another language and/or even choose a Function as a Service wrapper.
brlewis 8y ago
I like this article, but the title is misleading. "I did actually use some JavaScript on the new Slimvoice, but only when an interaction could not be replicated in any other way." Overall, the article does point in a good direction.
ryanolsonx 8y ago
This is pretty inspiring. I'm pretty interested to see their approach on the backend rendering. I've had some good experience in the good ol' days with server rendering.
twoquestions 8y ago
I gotta get better at CSS, I'm somewhat horrified by what I've done in JavaScript that it turns out I didn't need. Does anyone know of a good book on intermediate/advanced CSS to help avoid excess JS usage/complexity?
- ddoolin 8y ago
  http://shop.oreilly.com/product/0636920012726.do http://shop.oreilly.com/product/0636920012726.do I haven't used it personally BUT it seems to cover most things I'd use these days, including "new" topics like grid, filters, etc. CSS is relatively simple so something of a reference with some examples would be great.
- deleted 8y ago
  [deleted]
- pixelbash 8y ago
  An approach I use is to try and build something in css first, if I can't find a way to make it work then I'll break out the JavaScript. Css is surprisingly good in places, but it also drives me up the wall as soon as I let myself expect to be able to do more things in it. Yesterday it was gradient masks.
- zanny 8y ago
  MDN already has a bunch of courses on css: https://developer.mozilla.org/en-US/docs/Web/CSS https://developer.mozilla.org/en-US/docs/Web/CSS If you are already familiar with basic CSS skipping to the middle is fine. A lot of modern CSS is just discovery of what you can do since none of it is really all that intuitive, but I generally end up googling "how can I do X effect in CSS" and seeing what the consensus is. Just as some examples, you can do responsive bars that move all over the page, change their contents, have togglable collapse menus, have dropdown menus in those menus, etc all in plain CSS, but you can't have multiple columns of arbitrary sized elements in left to right top to bottom order. Learning CSS is really just learning the contemporary limits of what you can do and then ruining your lovely responsive grids and flexboxes with absolute positioned px garbage when you have to support IE as penance for your crimes.
- 8y ago
hliyan 8y ago
This is totally true. We've recently started to discover this paradox ourselves: when styling and layout is all done via CSS, and JS + other assets are cached, HTML is just as light weight as JSON over the wire. As ashamed as I am to admit it, our newest innovation appears to be "multi-page apps"!
- gambler 8y ago
  I remember there was some ridiculous article here where the author claimed to build world's fastest web app with PReact. It was a hierarchical list of HTML5 features with some tick-boxes. Out of curiosity I converted the giant JSON blob to <ul><li> list. HTML was about 15% smaller than JSON. You could also do most of the "logic" of the app via styling and normal HTML controls.
  - Geee 8y ago
    The benefit of JS comes in incremental updates. When you update that list with a new item, you can use optimistic update and small payloads in JS, while in HTML you have to load the whole page again, which is slower.
    - e12e 8y ago
      You have to load the whole page again. It may be slower.
    - gambler 8y ago
      Firstly, the application I was talking about[1] didn't have real updates. Secondly, no one stops you from doing incremental updates with HTML except they way you design your data structures and UI. In fact, HTML has something that JSON doesn't. Semantics. This means you can create a generic setup for incremental updates based, say, on element IDS. --- [1] https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7 https://hackernoon.com/10-things-i-learned-making-the-fastes...
    - mercer 8y ago
      The main issue I have with this idea is that in practice I've almost never found the difference in payload to matter all that much, even on bad connections. In some cases, even sending the entire HTML document and diffing on that using morphdom (because redrawing does bring noticeable cost rather quickly) was a viable strategy even compared to the most optimal json payload. I'd very much like to see some examples that prove me wrong though, because while I've done some experiments, I might be underestimating how complex many web apps are. It's mostly that the apps I built in hindsight were often better off with a more old fashioned server-side, morphdom, turbolinks (or maybe intercooler?) type approach.
coldtea 8y ago
One of the most inspiring web-related posts I've read in a long time...
julioneander 8y ago
Gotta shout out to the song linked in the article. Got me laughing good https://www.youtube.com/watch?v=Yx6k6WR8GRs https://www.youtube.com/watch?v=Yx6k6WR8GRs
ddoolin 8y ago
These are handy tricks, even in JS at scale, and I'd recommend their usage if you can (big if, business requirements come first for most of us). That said, I don't really buy into the no JS/purism movement for load/execution speed. For bite-sized apps or simple pages, sure. However, it's completely possible and not that hard to develop full-blown web application suites using full JS for everything (structure, style, and function) and not have issues with load or speed. I'm not sure if there's a footgun here, but the issue falls squarely on the developers.
- eeeeeeeeeeeee 8y ago
  Seems like once again people just need to pick the right tool for the job. The problem is that people get stuck into one framework and it’s familiar to them so it gets forced into a project it doesn’t make sense for down the road.
  - ddoolin 8y ago
    Couldn't agree more. Anybody sitting down to start a _serious_ project should spend some time possibly researching and definitely planning, which would hopefully lead to the right decision here.
  - mrec 8y ago
    "people just need to pick the right tool for the job" is utterly useless advice, just as "you should do the right thing" is an utterly useless answer to an ethics question, because it doesn't help you decide what the "right" tool/thing is. There are lots of considerations in answering that usefully. Fit for the particular problem domain is one of them, yes. But so is familiarity. And ease of hiring. And performance, stability, maturity, state of tooling, community, training resources and a zillion others. How do you balance all those? Wait, let me guess, "correctly". Sorry about the snark, this has just been a personal peeve of mine ever since the Slashdot days, when any word salad whatsoever would get upvoted Insightful provided it contained the magic phrase "right tool for the job".
    - ddoolin 8y ago
onion2k 8y ago
Since I'm caching and gzipping everything, each subsequent pageview is around 6 KB; far smaller than the SPAs I've seen with equivalent functionality. That's ace. But my internet connection has a 2 second latency so I still have to wait an annoyingly long time every time I interact with your app. My connection is terrible too, so it drops every 10th request, and now I'm seeing a lot of broken pages. If only you'd written an offline-first PWA and used background-loading and prefetching with some intelligence to retry failed requests in order to deliver content before I actually need it this would have worked so much better. But hey, the app is perfect for you on your robust wifi, so it must work out there in the real world, right? Snark aside, there's a good reason to build web software in a variety of different ways. Pick the one that suits your users. Don't assume everything works perfectly and every internet connection is strong, fast wifi. That just means a lot of users (especially poorer ones in rural communities) are going to struggle with what you're selling.
- jonstaab 8y ago
  Agree that an offline-first PWA is the way to go. Not _no_ javascript, just _as little as possible_. However, I've also not seen such a good example before of how doable this is, so thanks to the author for the show-and-tell. The label/checkbox example is a new one on me, and covers pretty near 80% of my use of javascript. It's interesting how when you strip html of all the DOM api nonsense it starts to look like an exciting new framework. Forms are such a nice, declarative way to get user input.
- peterbraden 8y ago
  Prefetching is going to waste data in a lot of the world where you pay by the megabyte. Everything is a tradeoff.
  - reificator 8y ago
    You prefetch what is required, and cache what is requested. Assuming you aren't one of the sites that thinks it's appropriate to require `DOOM.WAD`, it can work out well.
- lhorie 8y ago
tracker1 8y ago
Honestly, a lot of this comes down to ignorance on a lot of points. You can do a lot with CSS2.x+ selectors, and it's awesome. That said, JS/JSS and component systems aren't bad either. It depends on what you're creating and who your audience is. Most of this stuff isn't new, it's about a decade+ old at this point. Backend developers often tend to turn up their noses on web front ends, so they don't bother to actually learn anything meaningful, and just sit complaining constantly.
gambler 8y ago
This is pretty much how I develop most of my web stuff. I do use JS, but it comes in afterwards, in discrete packages. It process specific HTML attributes to make the page do extra stuff, or accelerate certain operations, or stich pages together via AJAX. All scripts are stateless, because all state is stored in HTML. The key is to represent your data and UI state via sane HTML. This article demonstrates this well with the modal popup example. Once you represent popup's state with a checkbox, you can manipulate that checkbox in any way you want and you can style it in any way you want and your styling will not have any dependencies on the methods of manipulation.
kgthegreat 8y ago
This is interesting and corresponds with the post https://builtwith.com/detailed/slimvoice.co https://builtwith.com/detailed/slimvoice.co
kaffee 8y ago
I like the slogan "JavaScript-free"! Finally something to rally around. I don't mind projects which use a tiny bit of hand-coded, vanilla ES6. Would be nice if there were a slogan that included these. Looks like it actually does use JavaScript for the "select2" case. This is exactly the case I'd be happy to special case. edit: added paragraph
- didgeoridoo 8y ago
  The term I've usually seen is "JS sprinkles". Not sure where it comes from — maybe DHH in the context of mostly-server-side Rails apps?
  - patrickxb 8y ago
    JS sprinkles became the stimulus package [1] [1] https://m.signalvnoise.com/stimulus-1-0-a-modest-javascript-framework-for-the-html-you-already-have/ https://m.signalvnoise.com/stimulus-1-0-a-modest-javascript-...
- mrec 8y ago
  http://vanilla-js.com/ http://vanilla-js.com/ It's got a badge and everything.
  - kaffee 8y ago
    This is cool. But it needs to be updated for ES6. The "Code Examples" could look even better now.
shove 8y ago
This is really great but I was really surprised by that 230k number. Expected ~150k
- winduptoy 8y ago
  Hey, author here. Just for reference, 180k of that is fonts. The rest is super tiny. Of course, once you've loaded it the first time, it's cached.
  - theandrewbailey 8y ago
    Have you tried minimizing that? Are you using WOFF2? Have you eliminated extra character sets/ranges? I know of a tool that can help: https://www.fontsquirrel.com/tools/webfont-generator https://www.fontsquirrel.com/tools/webfont-generator
    - winduptoy 8y ago
      Yes it's WOFF2, served over gzip. I do not think that I can eliminate extra character ranges because Slimvoice is used all over the world.
cannedslime 8y ago
Im not sure how elegant I think the CSS hack is compared to just making a simplistic script for it. Would a user really notice the parsing time for such a simple javascript application?
- HelloNurse 8y ago
  I object to considering the techniques in the article "hacks". They all employ minimal markup, without extra boxes or complicated classes, and the CSS side is very simple.
  - cannedslime 8y ago
    I give you that its not a verbose or complicated hack. but I still would say that a hidden checkbox acting as the middle man for modals etc is pretty hacky :). A hack doesn't need to be complicated, most times its not. But after all I can't imagine anyone thinking about this as a feature when they implemented checkbox inputs back in the days.
    - winduptoy 8y ago
      Author here. I agree that it's a hack and I can't say that I like it. Blame the W3C and browser vendors for providing incomplete/barely functional standards like <dialog>.
superkuh 8y ago
This write-up mostly highlights the loading speed and bandwidth benefits but not requiring javascript is far better than just that. In the age of spectre and with browsers exposing more and more bare metal functionality the idea of running arbitrary code on every random site I go to is absurd. There's dozens of us that simply don't run JS. Sites like these (and, say, the way chicago public media does fallback for no JS) show that there can still be pretty, functional sites without the modern equivalent of opening that .exe attached to a random email. Thanks and keep up the good fight.
- nkrisc 8y ago
  I'm not sure if you meant this or not, but there's text.npr.org. Honestly I'd prefer much of the web this way. I'd be OK with images too.
- pault 8y ago
  > There's dozens of us that simply don't run JS Was this intentional? It gave me a bit of a chuckle.
  - superkuh 8y ago
    It was an acknowledgement that there aren't enough people like myself for web devs at for profit businesses or institutions to care about.
  - roryokane 8y ago
    I saw some actual statistics recently on a link from a blog with a lot of posts about accessibility (I forget which). It said that 1 in 98 users (1% of visitors) didn’t load JavaScript in a page, and 0.2% of visitors didn’t load the script because they had explicitly disabled JavaScript, as opposed to other reasons such as a poor network connection.
zachguo 8y ago
What JS does can be reduced to several things: - storing states, and conditionally passing states around - toggling things on or off - element reuse - dealing with events - ajax Unfortunately it's unlikely HTML & CSS would support all these.
- kmlx 8y ago
  webrtc, webasm, webgl, and a million other things, right?
- btbuildem 8y ago
  Interactivity is a huge part -- moving things, adjusting parameters, live rendering, etc. Think D3, Crossfilter and such.
- lhorie 8y ago
  The paradigm shift here is that most of these things would be done in the server using traditional techniques: ajax, events, state are all handled via form submissions. The only things in this list that are really "frontend-ish" are element reuse (which, for styling purposes, is accomplished via CSS methodologies) and toggling things on/off, which in the CSS-only corners of the web is accomplished using a radio box CSS trick. Behavioral augmentation that these days is encapsulated via componentization (e.g. tabs, carousels) is also something that has been explored to death in traditional paradigms, e.g. unobtrusive js
  - zachguo 8y ago
    We all knew these tricks and started from there back in the day. Don't you think they are way too hacky? and cause too many page refreshes? Have you ever maintained codes mixing server-side templating and JS scripts? And there are so many edge cases popping up so that you have to use JS anyway. Then you may ask why don't I use JS for everything then? JS is inevitable no matter how you and I hate it. "JS-Free" only makes sense for simple presentations.
    - lhorie 8y ago
sbr464 8y ago
Nice work, I definitely appreciate the focus on simplicity/speed. I just signed up to check it out. I noticed on the invoice page, on mobile, the number inputs (qty, price, etc) showed the full alpha keyboard on input. I think you can add a few attributes to optimize, without using JS also. Great work, thanks for sharing. This link has been helpful for me: https://developers.google.com/web/fundamentals/design-and-ux/input/forms/ https://developers.google.com/web/fundamentals/design-and-ux...
- winduptoy 8y ago
  Thank you! I had no idea that iOS required the pattern="\d" attribute. Those inputs require a decimal, so that pattern won't actually work (something like pattern="\d\.?\d*"). If I can get my hands on an iPhone to test that, I will deploy it shortly!
  - sbr464 8y ago
    Awesome! Definitely a few hacks involved. I’ve seen different combinations of using pattern, type=number, step=“0.01” etc, but you may need support for longer decimals in qty/price. I’m always on the lookout for form best practices, but it’s definitely hard to stay up with all of the current trends. There are a few mobile preview tools, not sure which is currently best, for testing on different virtual devices: Google search: test site with iphone online
BornLikeThat 8y ago
weird flex, but okay
- buzzerbetrayed 8y ago
  I think you missed the entire point of the article. Your account also has 2 comments, and both of them are "weird flex, but okay". You are in the wrong place if you expect those comments to be appreciated.
kmlx 8y ago
it’s actually easy to do no-js websites when all you’ve got are forms, text and some images. but there are a lot of use cases where js is essential. it all comes down to what you’re building.
- snaky 8y ago
  You can even add huge "sign up for our newsletter!" text and button after every paragraph.
- winduptoy 8y ago
  Author here. Absolutely, and a ton of commenters (mostly on Reddit) seem to be missing that point. Use the right tool for the job. In the article I explicitly state that I couldn't have built the drag-and-drop invoice editor without JavaScript (although I wish that I could!).
bilater 8y ago
Naive question - but how could you do any interactions (login, add/edit stuff that talks to a server) without using Javascript?
- crooked-v 8y ago
  Form posts to the server, just like the old days. Of course, then you need a full page reload every time you edit something.
  - mrec 8y ago
    Not necessarily a full top-level page reload. You can POST to an iframe.
    - crooked-v 8y ago
      If you want to see the final status of the submission without JS, you still need at least part of the page to visibly reload.
- anderspitman 8y ago
  Hyperlinks
- winduptoy 8y ago
  Hey, author here. A lot of things are performed on the server, and then the server responds with a "flash" which is basically a little bar that says "Data saved." or "There was an error: ...". There are a few places where I used a simple 5-liner to validate a field or something. Unfortunately there was one place where I needed some heavier JS (for which I used Mithril.js), but it was absolutely required for when you're editing an invoice. You wouldn't want to edit line items and wait for a server response every time you make one change, so I simply determined that this was an area where I had no choice. Mithril simply modifies the DOM inside the <form> element, and then saving is a plain old POST request when you submit the form after you've made all of your changes. The unfortunate reality is that I couldn't completely free myself from JavaScript, but got a lot closer.
- 8y ago
ignaloidas 8y ago
To see more of this - sourcehut[0] uses most of these tricks and is open source so you can check out how they are used [0] https://sourcehut.org/ https://sourcehut.org/
_bxg1 8y ago
"Why can't we have a standard search element that filters a list on the client side (similar to how ng-repeat | filter: worked on Angular 1)?" It's pretty new, but: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... "Wouldn't a standard HTML element for drag-and-drop sorting be awesome?" There is a standard drag-and-drop API, but unfortunately (bafflingly) it's imperative/event-based, not declarative. Seems like it would be simple for them to add HTML hooks that use the same underlying code.
- chrisrickard 8y ago
  And a Datalist polyfill in the meantime https://github.com/mfranzke/datalist-polyfill https://github.com/mfranzke/datalist-polyfill (somewhat seems to defeat the nojs point though)
stcredzero 8y ago
Slimvoice - A Webapp Without JavaScript is a series where I document how I rebuilt my app, Slimvoice, using as little JavaScript as possible. Here's a recurring story in the programming field. A new variation on technology is highly successful. The field starts using it enthusiastically, but doesn't keep track of the costs and cost/benefit. The new tech gets rather overused. Some people come out with optimizations. (Usually involving what amounts to caching.) Other insightful contrarian people take a minimalist approach. Rinse and repeat. Once aware, one can spot this cycle happening. It is left as an exercise to the reader, how this can be used to profit.
- mercer 8y ago
  While I'm not a full-on no-js developer, my move to the back-end and less javascript has been one of the biggest reasons why I've started enjoying my job again. Unfortunately, at least judging by the many jobs I get offered, the market around me is still very much on the 'make everything a web app' train. I really hope the minimalist, or at least a less js-heavy approach actually becomes a new cycle, job-wise.
  - stcredzero 8y ago
    Funny, but the Smalltalk Seaside webapp framework was once criticized as old fashioned for this kind of server-centric, javascript minimal approach. And that wasn't that long ago.
d0bby 8y ago
Need to bump this. I hate JS.
cmclaughlin 8y ago
I've been using intercooler.js (http://intercoolerjs.org/ http://intercoolerjs.org/) on a project recently and absolutely love it... basically, it's allowed me to develop a web app with a modern feel without writing any JavaScript. Highly recommend it!
- ngrilly 8y ago
  Why the downvotes?
  - cmclaughlin 8y ago
    Can't imagine anyone that's tried intercooler.js would actually downvote. It's really nice and, in my opinion, totally addresses the author's concerns.
roebk 8y ago
It's perfectly possible to do some nifty tricks with CSS alone. The one thing this author has omitted is the impact this has on accessibility. Sure, I can open a modal without the need of JavaScript, but my focus isn't trapped within the modal and with no standard keyboard shortcut (ESC) to dismiss the modal, it provides a sub-standard experience for all users. Be sensible and use JavaScript when it's appropriate. Please don't think it's cool to create some fancy JS-less widgets and forget about accessibility.
- deleted 8y ago
  [deleted]
- gambler 8y ago
  You can trivially add keyboard shortcuts to this solution after it's implemented - with 0 rework. Moreover, the is absolutely no guarantee that an arbitrary JS library for modal popups will have better usability. And I have yet to see one that will not fail if I block JavaScript, creating horrible user experience for everyone who does so. Funny how usability concerns go out of the window when NoScript/uBlock users are involved. Personally, I try to avoid modal popups altogether. There is almost always better ways to structure things. The whole concept of "modal" UI doesn't map well to the "document" nature of web elements.
  - roebk 8y ago
    This is not simply about modals. Using VoiceOver and Chrome I cannot access the pop up menu to navigate the site. These CSS tricks are cool but they shouldn't be used in a production environment without basic usability testing. More specifically, no you cannot add keyboard shortcuts "with 0 rework". How are you returning the users focus to the active element before they opened the modal? The key is not to use an "arbitrary JS library for modal popups" and to use or create a modal library that has superior usability baked in. Sure, maybe there's a superior workflow than to use a modal. For anyone that is interested MicroModal (https://micromodal.now.sh/ https://micromodal.now.sh/) ticked a lot of boxes last time I checked.
    - 8y ago
KorematsuFred 8y ago
It is all about trade offs. We had a good application developed as a SPA and worked well. However we had a monetization flow where we took users credit card details and bunch of information. We developed this flow as a separate stand alone HTML pages and micro optimized, reduced css, used vanilla js and put it on CDN. That did bump up conversions by good percentage points. It is all about choosing the right hammer and nail for the job.
syphilis2 8y ago
Maybe this is nonsense, but I wish I had a way to lazily load content (images) without JavaScript. The JavaScript solution is very minimal, but maybe an HTML/CSS option would also be simple.
jordache 8y ago
well some needs to create a framework around this concept. Have the build process spit out only HTML and CSS that employ these exotic strategies. It's entirely unsustainable to have a team build an app using these patterns.
kabes 8y ago
> I built the first version of Slimvoice on Angular 1 with a Node.js backend and MongoDB in 2014 (those were all the rage back then). In 2015 I decided to completely revamp the UI and redesigned and rebuilt it in React. Maybe you should make decisions based on requirements instead of hype. Oh wait: > Don't follow the hype But using less javascript is the hype today... > Plain Old HTML and CSS This section only shows some very basic UI elements (dropdown, expansion panel, ...). This isn't what libraries like react solve. > Absolutely nothing is complex about my code I wouldn't label CSS hacks with invisible checkboxes under "simple and self-explanatory code". > I found myself wishing for more innovation in the HTML spec I don't think adding even more bloat to even more web standards than a browser already has to support is the anwser.
- pier25 8y ago
  > But using less javascript is the hype today... I don't know, the hype is usually In React, Vue, etc.
- pas 8y ago
  > HTML innovation not strictly HTML, but there's a lot of interesting goodies coming down the wire: https://css-houdini.rocks https://css-houdini.rocks https://ishoudinireadyyet.com https://ishoudinireadyyet.com
- MarkMyWordsMan 8y ago
  kabes is to the point! It is fashionable to hate on modern front-end frameworks these days. Imagine the OP grows their platform/company, hires a bunch of devs, what a nightmare that would be to keep avoiding JS and build on the product. All so just because using JS is so mainstream, ugh.
- nathan_long 8y ago
  > But using less javascript is the hype today... Is it? This article on npm weekly (https://medium.com/npm-inc/npm-weekly-133-billions-of-packages-downloaded-621a5196593 https://medium.com/npm-inc/npm-weekly-133-billions-of-packag...) says 4 billion packages were downloaded in a single week - representing multiple packages per week per human on earth. (Granted, this was Feb 2018, which is 2.8 millennia ago in JavaScript years.) This site (on which you can't use the back button after choosing a graph) seems to show downloads still growing for popular packages. https://www.npmtrends.com/ https://www.npmtrends.com/
deleted 8y ago
[deleted]
honkycat 8y ago
The very-immature Phoenix LiveView kind-of fits this use case. It looks AWESOME and I'm excited to watch it mature over time. Basically, LiveView is an Elixir library that allows SPA-style web page interactivity with server-rendered pages.
jypepin 8y ago
I had fun building our wedding website without any JS just to see how much I could push the boundaries of CSS and HTML. That was fun and a good learning experience. I'll now be able to build better apps _with JS_ knowing where it makes sense to push CSS/HTML and where it makes sense to use JS. I recommend any front end engineer to go through that exercise, but it is not a good solution for real production systems.
t0astbread 8y ago
This "no-JS" movement is cool and I love CSS hacks (in production?) but I also love the component mentality these JS-frameworks provide and not having to host frontend servers (other than for static files). Are there any good "pure" solutions for that?
roywiggins 8y ago
A nice way to progressively enhance something like this is to use Intercooler.js when you do want to update only part of the page. You're still just slinging HTML back to the browser but it lets you update only part of a page without using iframes or something, and since you're just adding data-attributes to links and forms, you don't write any javascript.
- slow_donkey 8y ago
  I would suggest using Vue progressively at that point. Refactoring our endpoints after using intercooler was not fun and using Vue/react without going full SPA let's you move on way easier
MarkMyWordsMan 8y ago
Is it popular to hate on JS these days? Kudos to the author for creating the stuff but would you build the next Amazon.com avoiding JS? More often than not, I see Backend developers taking pride on not using JS rather than vice versa. Also, FB and GOOG aren't naive to spend enormous capital and manpower on React and Angular projects. Probably will get downvoted but just because someone writes pure C does not make him/her a better developer than someone who just writes Javascript.
- x3ro 8y ago
  I'm still trying to grasp why these discussions so quickly spin into extremes. The author clearly states her intent in the first paragraph: > With the new version I wanted to prove that it was possible to deliver an amazing user experience with a great design while drastically reducing the complexity of the code, maximizing reliability, and minimizing the cost to the end user. She goes on to show us what she did, where it worked and where it didn't. The most important points I take away from her article are: 1. It's quite possible to build nice-feeling (YMMV), non-single-page web-apps without (a ton of) JavaScript 2. Critically evaluate if you need the complexity that an enormous JS framework brings > You probably don't need a "Progressive Web App." Seriously evaluate if your app needs such complexity. This has nothing to do with FAANG. Nobody disputes that there are use cases where it's a really good idea to use React+Redux+Jest+Enzyme+XYZ et al. But _maybe_ (and in my personal experience, in projects significantly smaller than Amazon.com, often) you simply do not need that amount of additional complexity and challenges. It'd be so nice to just accept that the author provides an interesting data point (it can work without JS) in a community strongly biased towards starting projects by importing ~1000 node modules.
- HelloNurse 8y ago
  It is somewhat popular to hate on useless dung heaps of pointless Javascript, not because it's Javascript (writing complex code in a mediocre language with mediocre libraries is a separate concern), nor because backend developers have good reasons to do things in the backend, but because it's overcomplicated and so bloated that it causes performance problems, just like nested table layouts a few years ago.
ryanmarsh 8y ago
While I understand the concern about bloated frontends, I do not understand the throw-the-baby-out-with-the-bathwater mentality of JavaScript-free front-ends. Furthermore I feel like there's a misplaced sense of pastoralism or nostalgia about the-web-before-JavaScript. The fact is there was a very brief period where the World Wide Web was both widely accessible to the public and JavaScript free. I built my first website without JavaScript in 1995. By 1997 I was building incredibly interactive single page apps in IE4 with JavaScript and DHTML (as it was called at the time). By 1998 my full time job was writing cross-browser JavaScript. That's twenty years ago folks. jQuery didn't hit the scene until 2006. Why was jQuery created? Was it a revolutionary new tool that gave us the ability to create applications that heretofore had never been seen? Or, was it created to tame the horrendous mass of JavaScript that had already accumulated? We can talk about bloat, but let's be honest about what the web browser is now. Chrome is an application container. The web hasn't been purely hypertext for a long time. Back when it was we complained about the bloat... of images
Justsignedup 8y ago
It is hard to argue against using JS. I tried that no-js approach as much as possible in the past, and hated it. Using React for front-end development and keeping bundle sizes small through good build processes is amazing. I genuinely enjoy building web front-ends now because of it, where as before I avoided it like the plague.
NightlyDev 8y ago
I totally agree that js is used way too much and dependencies are often included without ever considering the consequences. But Javascript itself isn't bad. Just use it when it makes sense, and minimize it. Remove any dead code so phones won't have to spend cpu and data on it.
robmccoll 8y ago
I'm amused by the Javascript mouse tracking used to rotate the phone image on the first page.
- buzzerbetrayed 8y ago
  I thought the same thing. Of all the places that javascript could have been cut out, that had to be the most obvious.
ghostbrainalpha 8y ago
A website without JavaScript is like this comment.
freeopinion 8y ago
> I wanted to prove that it was possible to deliver an amazing user experience with a great design while drastically reducing the complexity of the code, maximizing reliability, and minimizing the cost to the end user. ... > The Website Obesity Problem is not getting any better for the web at large. These are both important points. But remember that 50MB of CSS stylesheets is still very obese and very complex. Replacing bloated JS with bloated CSS is of arguable value. Just saying...
anthony_doan 8y ago
There is something like that the Elixir web community is trying to do with Liveview, Texas, Morphling and Whistle. Several competing libraries doing the same thing I believe, I've only seen Texas and Liveview in action. The whole point, iirc, is to manipulate the DOM on server side and push those changes via a websocket. So the DOM manipulation is on server side and the code is server side language Elixir. There was a demo for Texas and Liveview which show pretty good performance. I'm not sure if it is good enough performance but it looks promising. Video for Texas: https://www.youtube.com/watch?v=NWgwUKfR8Xg https://www.youtube.com/watch?v=NWgwUKfR8Xg Video for LiveView: https://dockyard.com/blog/2018/09/12/liveview-project-at-elixirconf-2018 https://dockyard.com/blog/2018/09/12/liveview-project-at-eli...
- mercer 8y ago
  I've played around with sending html strings via Phoenix channels and using morphdom to change only what needs to be changed. I'm quite happy with the results, even when sending an entire page for every significant change, and can't wait for LiveView to be released (estimated later this month, IIRC).
erikpukinskis 8y ago
I don't see how you go from "giant JS payloads that can render your whole site are bad" to "don't use Javascript to hide a DIV". Maybe the CSS hack is faster than onclick="document.getElementById('zip-code-modal').style.display = 'none'" but it's quite likely not.
duchenne 8y ago
How do you guys achieve this in practice? I made my home page without javascript, and it is blazing fast. But as soon as I try to make something more complicated I bumped into practical problems. - Components. I want to have the same navbar on all my pages, but I don't want an un-maintainable copy-pasted code on all my pages. - Data. I need to display some data that is different for each user. How do I embed it in my webpage without ajax calls? - Dev tools. I need debugging / bundler / source maps. Some possible solutions could be: - PHP. It has components through "require". You can embed the data easily. But, I do not know good dev tools: If I debug the javascript in the chrome dev tools, can I edit directly the php script? Can I minify/babel the output of the php code? And I cannot use the same php code on both front-end and back-end. - Vue-SSR. Nice one-file components. Data can be provided within express. I can re-use the same code on the front-end. I have not tried yet, but it seems very interesting. - EJS. It has require and data from express. It is very simple too use. But the tooling is lacking: no source map.
- cfv 8y ago
  Just a stupid question. Why would you need a bundler for plain HTML? I agree on everything else, but I kinda tripped on that and I'm not sure what you're actually looking for.
  - duchenne 8y ago
    If you have a solution to avoid using a bundler altogether, that would be great. Personally, I would use it for: - compression of html/css/images. - css compatibility with old browsers. - source map / auto-refresh during development. - For any even slightly complicated app, you still need at least a bit of javascript. So, you need babel, minification, source maps, and so on...
- pdimitar 8y ago
  Err, isn't everything you are worried about also served quite well by all server-side rendering frameworks since forever? I legitimately cannot understand your issue.
  - 8y ago
cfv 8y ago
So I decided to try and figure out this specific trick about toggling content and how well this would actually work in, say, a tab panel. I mean, it is a cute trick right? I made this: https://jsfiddle.net/sr8z1mob/6/ https://jsfiddle.net/sr8z1mob/6/ Yes, it is a cute trick. Yes, it CAN be made more accessible, and kinda sorta avoids the most obvious problems with like tabindexes and so on, although it did take a lot of work on my end for such an insignificant demonstrator, and I can't still set the active tab by hand in any way in here. Which is a rather important cue about it's capabilities. There's other things I cannot do: - Use this as an actual component! I would have to set up an editor expansion to type all this stuff each time I wanted a tablist, and I cannot globally modify how all of them work. Making this into some kind of custom tag would be GREAT, but it could also probably mean going back to .htc files which is not so great. - Track user interaction! It's important to us to know what the user is doing with our product so we can make it better. - Auto-select the first tab's content in all tablists without contorting my brain into a cramp - Load the tab contents lazily. Maybe you don't need the King James Bible (replace with any other long blob you like) loaded in there by default, just when you actually want to go look at the thing. - Skin the scrollbar easily (OSX for instance is a major PITA I'd like to have auto-solved for me) - Tell the server when the tab was scrolled to the bottom - Did I mention I cannot mark the current tab as open in any real meaningful way? This is a fun experiment. But really, it all boils down to requirements and development times. Do you have the time and energy to spare to twist the browser into doing this kind of things? That's awesome! I, more often than not, don't. That's sort of the reason why we use a development framework that puts us into a mindset we can work better with to cover more ellaborate scenarios (like being able to mark the currently open tab as exactly that without having to think about doing it).
ritty 8y ago
I admit it, I hate single page apps. I see very few that actually work well. I don't hate JavaScript, it has its place, but you don't need to make an entire website an SPA. Stuff like the main Spotify, Slack, or Discord pages, and even things like Google Docs, and email front ends are fine for SPA. But you don't need to also embed all the FAQs and other crap into the SPA. You know what isn't an SPA? Hacker News. You know what else isn't? Google, GitHub, Amazon, and Stack Overflow. I've disabled the SPA version of Reddit. I've built SPAs and they are so much harder and take so much longer to develop and maintain than traditional web sites. I wish they'd just die. Sadly, everyone else at my work orgasms about SPAs, pushing every damn thing into it. We have stuff that works perfectly well and no one has ever complained about it? Screw it, let's spend $50k turning that feature into an SPA. I know many of you disagree with me and I'll get off my soap box now. </vent>
masswerk 8y ago
Last year, I relaunched my website with just CSS – and I'm not missing anything. JS is used just for the error pages, featuring a game as optional content. :-)
RobKohr 8y ago
I think this ignores one of the main benefits of JS based page rendering. In the days where I worked on PHP apps, all rendering was done on the server, and that came at a great cost regarding server side processing and the complexities of peak load times, along with some pretty hairy test cases. With everything rendered in js, you are mostly just transferring static assets, so the browsers are doing the heavy lifting for you. The only things that end up taking up server CPU cycles and system memory were API calls that are easy to test, debug, and optimize. Also, those API calls can be cached, and become static assets for high traffic apis such as ones accessed on the front end. If you do it all on the backend, you are doing all the rendering work, and it is hard to split off and optimize processing time for things. Finally, for testing, it is really easy to unit test an API, and for javascript frontend work, there doesn't seem to be the code regression type bugs that are so time consuming, but when you mix the data api stuff with the front end rendering, unit testing becomes a big mess. Bloat needs to be thought about, especially for limiting bandwidth, but just for curiosity, I checked out my own website which was using React and a bunch of libraries, and it was only 500K. This is about half the size of the banner image on that article. Some libraries are much larger than React, but going JS free and losing the power React gives you doesn't seem like a good trade off. Of course if you get some happys from being an ultra-purist, then I get that, and that is priceless. From a practical perspective though, this seems misguided.

484 points by bibyte 8y ago

asdfasdfdavid 8y ago

This is beautiful!

blue4 8y ago

wow this is excellent, <details>/<summary> are good tricks

elhenrico 8y ago
And contrary to the article, it is possible to change their style!
technotarek 8y ago
Except for the "works everywhere" suggestion... https://caniuse.com/#feat=details https://caniuse.com/#feat=details And here I thought Edge was a modern browser.
- blunte 8y ago
  Given that Edge has less than 5% marketshare globally (depending on the source of the information), I would say that fretting over compatibility with it is not a priority. And given that MS is moving Edge to Chromium rendering engine, I assume this will solve the compat problem.
  - technotarek 8y ago
    5% can still be a decent number of users, and tends to trend even higher in certain segments (state and local government, smaller "old economy" businesses)
- dictum 8y ago
  It's a basic DOM element — a block of content. Without native support, it's simply shown by default, instead of hidden by default, so nothing is broken, and even the default on non-supporting browsers can be changed with JS and CSS. If anything, this is the works everywheriest of things that "work everywhere" in post-2010 web development. Some other stuff actually breaks accessibility by default.
  - technotarek 8y ago
    Thx. Good to know. In that case, selective usage seems like good policy.

andrewfromx 8y ago

100 percent agree. Use as little JS as possible on front end. And then definitely use zero JS on backend.

tracker1 8y ago
Definitely...only use C on the backend, any other language is just a hack.
- sixstringtheory 8y ago
  I get the snark, but Java, Rust, Erlang are all better options than an interpreted language for backends IMO
  - Scarbutt 8y ago
    nodejs and expressjs are pretty solid stable tools these days. And there is always typescript if you are into that.
  - tracker1 8y ago
    Define better... Scripted languages can be run without the need for a compilation step, if you're scaling horizontally anyway, you can do nearly as well with node, and node can handle 100k+ connections per core with minimalish memory overhead. Functions are first class, functional approaches are easy and flexible, and when you're just passing bytes to another system or database, JS/Node works well. As to interpreted languages, JS/V8 has probably seen more optimization than any other interpreted language. As to Java, you don't need a 400-500mb base image either. Rust takes much longer to develop against, as does erlang even if you're familiar with it. If you're parsing JSON into concrete objects, the overhead is often larger with compiled languages than interpreted, where JS just works. I can generally get stuff working in around 1/8 the time it takes for peers to use a compiled language to do the same. Go is probably a better option than the three you suggested, even then more often than not, I would choose node, just because of the flexibility I get with npm and the larger community. If I, in turn need to eek more performance, or have a process that requires more compute per request, then I'll often reach for another language and/or even choose a Function as a Service wrapper.

brlewis 8y ago

I like this article, but the title is misleading. "I did actually use some JavaScript on the new Slimvoice, but only when an interaction could not be replicated in any other way." Overall, the article does point in a good direction.

ryanolsonx 8y ago

This is pretty inspiring. I'm pretty interested to see their approach on the backend rendering. I've had some good experience in the good ol' days with server rendering.

twoquestions 8y ago

I gotta get better at CSS, I'm somewhat horrified by what I've done in JavaScript that it turns out I didn't need. Does anyone know of a good book on intermediate/advanced CSS to help avoid excess JS usage/complexity?

ddoolin 8y ago
http://shop.oreilly.com/product/0636920012726.do http://shop.oreilly.com/product/0636920012726.do I haven't used it personally BUT it seems to cover most things I'd use these days, including "new" topics like grid, filters, etc. CSS is relatively simple so something of a reference with some examples would be great.
deleted 8y ago
[deleted]
pixelbash 8y ago
An approach I use is to try and build something in css first, if I can't find a way to make it work then I'll break out the JavaScript. Css is surprisingly good in places, but it also drives me up the wall as soon as I let myself expect to be able to do more things in it. Yesterday it was gradient masks.
zanny 8y ago
MDN already has a bunch of courses on css: https://developer.mozilla.org/en-US/docs/Web/CSS https://developer.mozilla.org/en-US/docs/Web/CSS If you are already familiar with basic CSS skipping to the middle is fine. A lot of modern CSS is just discovery of what you can do since none of it is really all that intuitive, but I generally end up googling "how can I do X effect in CSS" and seeing what the consensus is. Just as some examples, you can do responsive bars that move all over the page, change their contents, have togglable collapse menus, have dropdown menus in those menus, etc all in plain CSS, but you can't have multiple columns of arbitrary sized elements in left to right top to bottom order. Learning CSS is really just learning the contemporary limits of what you can do and then ruining your lovely responsive grids and flexboxes with absolute positioned px garbage when you have to support IE as penance for your crimes.
8y ago

hliyan 8y ago

This is totally true. We've recently started to discover this paradox ourselves: when styling and layout is all done via CSS, and JS + other assets are cached, HTML is just as light weight as JSON over the wire. As ashamed as I am to admit it, our newest innovation appears to be "multi-page apps"!

gambler 8y ago
I remember there was some ridiculous article here where the author claimed to build world's fastest web app with PReact. It was a hierarchical list of HTML5 features with some tick-boxes. Out of curiosity I converted the giant JSON blob to <ul><li> list. HTML was about 15% smaller than JSON. You could also do most of the "logic" of the app via styling and normal HTML controls.
- Geee 8y ago
  The benefit of JS comes in incremental updates. When you update that list with a new item, you can use optimistic update and small payloads in JS, while in HTML you have to load the whole page again, which is slower.
  - e12e 8y ago
    You have to load the whole page again. It may be slower.
  - gambler 8y ago
    Firstly, the application I was talking about[1] didn't have real updates. Secondly, no one stops you from doing incremental updates with HTML except they way you design your data structures and UI. In fact, HTML has something that JSON doesn't. Semantics. This means you can create a generic setup for incremental updates based, say, on element IDS. --- [1] https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7 https://hackernoon.com/10-things-i-learned-making-the-fastes...
  - mercer 8y ago
    The main issue I have with this idea is that in practice I've almost never found the difference in payload to matter all that much, even on bad connections. In some cases, even sending the entire HTML document and diffing on that using morphdom (because redrawing does bring noticeable cost rather quickly) was a viable strategy even compared to the most optimal json payload. I'd very much like to see some examples that prove me wrong though, because while I've done some experiments, I might be underestimating how complex many web apps are. It's mostly that the apps I built in hindsight were often better off with a more old fashioned server-side, morphdom, turbolinks (or maybe intercooler?) type approach.

coldtea 8y ago

One of the most inspiring web-related posts I've read in a long time...

julioneander 8y ago

Gotta shout out to the song linked in the article. Got me laughing good https://www.youtube.com/watch?v=Yx6k6WR8GRs https://www.youtube.com/watch?v=Yx6k6WR8GRs

ddoolin 8y ago

These are handy tricks, even in JS at scale, and I'd recommend their usage if you can (big if, business requirements come first for most of us). That said, I don't really buy into the no JS/purism movement for load/execution speed. For bite-sized apps or simple pages, sure. However, it's completely possible and not that hard to develop full-blown web application suites using full JS for everything (structure, style, and function) and not have issues with load or speed. I'm not sure if there's a footgun here, but the issue falls squarely on the developers.

eeeeeeeeeeeee 8y ago
Seems like once again people just need to pick the right tool for the job. The problem is that people get stuck into one framework and it’s familiar to them so it gets forced into a project it doesn’t make sense for down the road.
- ddoolin 8y ago
  Couldn't agree more. Anybody sitting down to start a _serious_ project should spend some time possibly researching and definitely planning, which would hopefully lead to the right decision here.
- mrec 8y ago
  "people just need to pick the right tool for the job" is utterly useless advice, just as "you should do the right thing" is an utterly useless answer to an ethics question, because it doesn't help you decide what the "right" tool/thing is. There are lots of considerations in answering that usefully. Fit for the particular problem domain is one of them, yes. But so is familiarity. And ease of hiring. And performance, stability, maturity, state of tooling, community, training resources and a zillion others. How do you balance all those? Wait, let me guess, "correctly". Sorry about the snark, this has just been a personal peeve of mine ever since the Slashdot days, when any word salad whatsoever would get upvoted Insightful provided it contained the magic phrase "right tool for the job".
  - ddoolin 8y ago

onion2k 8y ago

Since I'm caching and gzipping everything, each subsequent pageview is around 6 KB; far smaller than the SPAs I've seen with equivalent functionality. That's ace. But my internet connection has a 2 second latency so I still have to wait an annoyingly long time every time I interact with your app. My connection is terrible too, so it drops every 10th request, and now I'm seeing a lot of broken pages. If only you'd written an offline-first PWA and used background-loading and prefetching with some intelligence to retry failed requests in order to deliver content before I actually need it this would have worked so much better. But hey, the app is perfect for you on your robust wifi, so it must work out there in the real world, right? Snark aside, there's a good reason to build web software in a variety of different ways. Pick the one that suits your users. Don't assume everything works perfectly and every internet connection is strong, fast wifi. That just means a lot of users (especially poorer ones in rural communities) are going to struggle with what you're selling.

jonstaab 8y ago
Agree that an offline-first PWA is the way to go. Not _no_ javascript, just _as little as possible_. However, I've also not seen such a good example before of how doable this is, so thanks to the author for the show-and-tell. The label/checkbox example is a new one on me, and covers pretty near 80% of my use of javascript. It's interesting how when you strip html of all the DOM api nonsense it starts to look like an exciting new framework. Forms are such a nice, declarative way to get user input.
peterbraden 8y ago
Prefetching is going to waste data in a lot of the world where you pay by the megabyte. Everything is a tradeoff.
- reificator 8y ago
  You prefetch what is required, and cache what is requested. Assuming you aren't one of the sites that thinks it's appropriate to require `DOOM.WAD`, it can work out well.
lhorie 8y ago

tracker1 8y ago

Honestly, a lot of this comes down to ignorance on a lot of points. You can do a lot with CSS2.x+ selectors, and it's awesome. That said, JS/JSS and component systems aren't bad either. It depends on what you're creating and who your audience is. Most of this stuff isn't new, it's about a decade+ old at this point. Backend developers often tend to turn up their noses on web front ends, so they don't bother to actually learn anything meaningful, and just sit complaining constantly.

gambler 8y ago

This is pretty much how I develop most of my web stuff. I do use JS, but it comes in afterwards, in discrete packages. It process specific HTML attributes to make the page do extra stuff, or accelerate certain operations, or stich pages together via AJAX. All scripts are stateless, because all state is stored in HTML. The key is to represent your data and UI state via sane HTML. This article demonstrates this well with the modal popup example. Once you represent popup's state with a checkbox, you can manipulate that checkbox in any way you want and you can style it in any way you want and your styling will not have any dependencies on the methods of manipulation.

kgthegreat 8y ago

This is interesting and corresponds with the post https://builtwith.com/detailed/slimvoice.co https://builtwith.com/detailed/slimvoice.co

kaffee 8y ago

I like the slogan "JavaScript-free"! Finally something to rally around. I don't mind projects which use a tiny bit of hand-coded, vanilla ES6. Would be nice if there were a slogan that included these. Looks like it actually does use JavaScript for the "select2" case. This is exactly the case I'd be happy to special case. edit: added paragraph

didgeoridoo 8y ago
The term I've usually seen is "JS sprinkles". Not sure where it comes from — maybe DHH in the context of mostly-server-side Rails apps?
- patrickxb 8y ago
  JS sprinkles became the stimulus package [1] [1] https://m.signalvnoise.com/stimulus-1-0-a-modest-javascript-framework-for-the-html-you-already-have/ https://m.signalvnoise.com/stimulus-1-0-a-modest-javascript-...
mrec 8y ago
http://vanilla-js.com/ http://vanilla-js.com/ It's got a badge and everything.
- kaffee 8y ago
  This is cool. But it needs to be updated for ES6. The "Code Examples" could look even better now.

shove 8y ago

This is really great but I was really surprised by that 230k number. Expected ~150k

winduptoy 8y ago
Hey, author here. Just for reference, 180k of that is fonts. The rest is super tiny. Of course, once you've loaded it the first time, it's cached.
- theandrewbailey 8y ago
  Have you tried minimizing that? Are you using WOFF2? Have you eliminated extra character sets/ranges? I know of a tool that can help: https://www.fontsquirrel.com/tools/webfont-generator https://www.fontsquirrel.com/tools/webfont-generator
  - winduptoy 8y ago
    Yes it's WOFF2, served over gzip. I do not think that I can eliminate extra character ranges because Slimvoice is used all over the world.

cannedslime 8y ago

Im not sure how elegant I think the CSS hack is compared to just making a simplistic script for it. Would a user really notice the parsing time for such a simple javascript application?

HelloNurse 8y ago
I object to considering the techniques in the article "hacks". They all employ minimal markup, without extra boxes or complicated classes, and the CSS side is very simple.
- cannedslime 8y ago
  I give you that its not a verbose or complicated hack. but I still would say that a hidden checkbox acting as the middle man for modals etc is pretty hacky :). A hack doesn't need to be complicated, most times its not. But after all I can't imagine anyone thinking about this as a feature when they implemented checkbox inputs back in the days.
  - winduptoy 8y ago
    Author here. I agree that it's a hack and I can't say that I like it. Blame the W3C and browser vendors for providing incomplete/barely functional standards like <dialog>.

superkuh 8y ago

This write-up mostly highlights the loading speed and bandwidth benefits but not requiring javascript is far better than just that. In the age of spectre and with browsers exposing more and more bare metal functionality the idea of running arbitrary code on every random site I go to is absurd. There's dozens of us that simply don't run JS. Sites like these (and, say, the way chicago public media does fallback for no JS) show that there can still be pretty, functional sites without the modern equivalent of opening that .exe attached to a random email. Thanks and keep up the good fight.

nkrisc 8y ago
I'm not sure if you meant this or not, but there's text.npr.org. Honestly I'd prefer much of the web this way. I'd be OK with images too.
pault 8y ago
> There's dozens of us that simply don't run JS Was this intentional? It gave me a bit of a chuckle.
- superkuh 8y ago
  It was an acknowledgement that there aren't enough people like myself for web devs at for profit businesses or institutions to care about.
- roryokane 8y ago
  I saw some actual statistics recently on a link from a blog with a lot of posts about accessibility (I forget which). It said that 1 in 98 users (1% of visitors) didn’t load JavaScript in a page, and 0.2% of visitors didn’t load the script because they had explicitly disabled JavaScript, as opposed to other reasons such as a poor network connection.

zachguo 8y ago

What JS does can be reduced to several things: - storing states, and conditionally passing states around - toggling things on or off - element reuse - dealing with events - ajax Unfortunately it's unlikely HTML & CSS would support all these.

kmlx 8y ago
webrtc, webasm, webgl, and a million other things, right?
btbuildem 8y ago
Interactivity is a huge part -- moving things, adjusting parameters, live rendering, etc. Think D3, Crossfilter and such.
lhorie 8y ago
The paradigm shift here is that most of these things would be done in the server using traditional techniques: ajax, events, state are all handled via form submissions. The only things in this list that are really "frontend-ish" are element reuse (which, for styling purposes, is accomplished via CSS methodologies) and toggling things on/off, which in the CSS-only corners of the web is accomplished using a radio box CSS trick. Behavioral augmentation that these days is encapsulated via componentization (e.g. tabs, carousels) is also something that has been explored to death in traditional paradigms, e.g. unobtrusive js
- zachguo 8y ago
  We all knew these tricks and started from there back in the day. Don't you think they are way too hacky? and cause too many page refreshes? Have you ever maintained codes mixing server-side templating and JS scripts? And there are so many edge cases popping up so that you have to use JS anyway. Then you may ask why don't I use JS for everything then? JS is inevitable no matter how you and I hate it. "JS-Free" only makes sense for simple presentations.
  - lhorie 8y ago

sbr464 8y ago

Nice work, I definitely appreciate the focus on simplicity/speed. I just signed up to check it out. I noticed on the invoice page, on mobile, the number inputs (qty, price, etc) showed the full alpha keyboard on input. I think you can add a few attributes to optimize, without using JS also. Great work, thanks for sharing. This link has been helpful for me: https://developers.google.com/web/fundamentals/design-and-ux/input/forms/ https://developers.google.com/web/fundamentals/design-and-ux...

winduptoy 8y ago
Thank you! I had no idea that iOS required the pattern="\d" attribute. Those inputs require a decimal, so that pattern won't actually work (something like pattern="\d\.?\d*"). If I can get my hands on an iPhone to test that, I will deploy it shortly!
- sbr464 8y ago
  Awesome! Definitely a few hacks involved. I’ve seen different combinations of using pattern, type=number, step=“0.01” etc, but you may need support for longer decimals in qty/price. I’m always on the lookout for form best practices, but it’s definitely hard to stay up with all of the current trends. There are a few mobile preview tools, not sure which is currently best, for testing on different virtual devices: Google search: test site with iphone online

BornLikeThat 8y ago

weird flex, but okay

buzzerbetrayed 8y ago
I think you missed the entire point of the article. Your account also has 2 comments, and both of them are "weird flex, but okay". You are in the wrong place if you expect those comments to be appreciated.

kmlx 8y ago

it’s actually easy to do no-js websites when all you’ve got are forms, text and some images. but there are a lot of use cases where js is essential. it all comes down to what you’re building.

snaky 8y ago
You can even add huge "sign up for our newsletter!" text and button after every paragraph.
winduptoy 8y ago
Author here. Absolutely, and a ton of commenters (mostly on Reddit) seem to be missing that point. Use the right tool for the job. In the article I explicitly state that I couldn't have built the drag-and-drop invoice editor without JavaScript (although I wish that I could!).

bilater 8y ago

Naive question - but how could you do any interactions (login, add/edit stuff that talks to a server) without using Javascript?

crooked-v 8y ago
Form posts to the server, just like the old days. Of course, then you need a full page reload every time you edit something.
- mrec 8y ago
  Not necessarily a full top-level page reload. You can POST to an iframe.
  - crooked-v 8y ago
    If you want to see the final status of the submission without JS, you still need at least part of the page to visibly reload.
anderspitman 8y ago
Hyperlinks
winduptoy 8y ago
Hey, author here. A lot of things are performed on the server, and then the server responds with a "flash" which is basically a little bar that says "Data saved." or "There was an error: ...". There are a few places where I used a simple 5-liner to validate a field or something. Unfortunately there was one place where I needed some heavier JS (for which I used Mithril.js), but it was absolutely required for when you're editing an invoice. You wouldn't want to edit line items and wait for a server response every time you make one change, so I simply determined that this was an area where I had no choice. Mithril simply modifies the DOM inside the <form> element, and then saving is a plain old POST request when you submit the form after you've made all of your changes. The unfortunate reality is that I couldn't completely free myself from JavaScript, but got a lot closer.
8y ago

ignaloidas 8y ago

To see more of this - sourcehut[0] uses most of these tricks and is open source so you can check out how they are used [0] https://sourcehut.org/ https://sourcehut.org/

_bxg1 8y ago

"Why can't we have a standard search element that filters a list on the client side (similar to how ng-repeat | filter: worked on Angular 1)?" It's pretty new, but: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... "Wouldn't a standard HTML element for drag-and-drop sorting be awesome?" There is a standard drag-and-drop API, but unfortunately (bafflingly) it's imperative/event-based, not declarative. Seems like it would be simple for them to add HTML hooks that use the same underlying code.

chrisrickard 8y ago
And a Datalist polyfill in the meantime https://github.com/mfranzke/datalist-polyfill https://github.com/mfranzke/datalist-polyfill (somewhat seems to defeat the nojs point though)

stcredzero 8y ago

Slimvoice - A Webapp Without JavaScript is a series where I document how I rebuilt my app, Slimvoice, using as little JavaScript as possible. Here's a recurring story in the programming field. A new variation on technology is highly successful. The field starts using it enthusiastically, but doesn't keep track of the costs and cost/benefit. The new tech gets rather overused. Some people come out with optimizations. (Usually involving what amounts to caching.) Other insightful contrarian people take a minimalist approach. Rinse and repeat. Once aware, one can spot this cycle happening. It is left as an exercise to the reader, how this can be used to profit.

mercer 8y ago
While I'm not a full-on no-js developer, my move to the back-end and less javascript has been one of the biggest reasons why I've started enjoying my job again. Unfortunately, at least judging by the many jobs I get offered, the market around me is still very much on the 'make everything a web app' train. I really hope the minimalist, or at least a less js-heavy approach actually becomes a new cycle, job-wise.
- stcredzero 8y ago
  Funny, but the Smalltalk Seaside webapp framework was once criticized as old fashioned for this kind of server-centric, javascript minimal approach. And that wasn't that long ago.

d0bby 8y ago

Need to bump this. I hate JS.

cmclaughlin 8y ago

I've been using intercooler.js (http://intercoolerjs.org/ http://intercoolerjs.org/) on a project recently and absolutely love it... basically, it's allowed me to develop a web app with a modern feel without writing any JavaScript. Highly recommend it!

ngrilly 8y ago
Why the downvotes?
- cmclaughlin 8y ago
  Can't imagine anyone that's tried intercooler.js would actually downvote. It's really nice and, in my opinion, totally addresses the author's concerns.

roebk 8y ago

It's perfectly possible to do some nifty tricks with CSS alone. The one thing this author has omitted is the impact this has on accessibility. Sure, I can open a modal without the need of JavaScript, but my focus isn't trapped within the modal and with no standard keyboard shortcut (ESC) to dismiss the modal, it provides a sub-standard experience for all users. Be sensible and use JavaScript when it's appropriate. Please don't think it's cool to create some fancy JS-less widgets and forget about accessibility.

deleted 8y ago
[deleted]
gambler 8y ago
You can trivially add keyboard shortcuts to this solution after it's implemented - with 0 rework. Moreover, the is absolutely no guarantee that an arbitrary JS library for modal popups will have better usability. And I have yet to see one that will not fail if I block JavaScript, creating horrible user experience for everyone who does so. Funny how usability concerns go out of the window when NoScript/uBlock users are involved. Personally, I try to avoid modal popups altogether. There is almost always better ways to structure things. The whole concept of "modal" UI doesn't map well to the "document" nature of web elements.
- roebk 8y ago
  This is not simply about modals. Using VoiceOver and Chrome I cannot access the pop up menu to navigate the site. These CSS tricks are cool but they shouldn't be used in a production environment without basic usability testing. More specifically, no you cannot add keyboard shortcuts "with 0 rework". How are you returning the users focus to the active element before they opened the modal? The key is not to use an "arbitrary JS library for modal popups" and to use or create a modal library that has superior usability baked in. Sure, maybe there's a superior workflow than to use a modal. For anyone that is interested MicroModal (https://micromodal.now.sh/ https://micromodal.now.sh/) ticked a lot of boxes last time I checked.
  - 8y ago

KorematsuFred 8y ago

It is all about trade offs. We had a good application developed as a SPA and worked well. However we had a monetization flow where we took users credit card details and bunch of information. We developed this flow as a separate stand alone HTML pages and micro optimized, reduced css, used vanilla js and put it on CDN. That did bump up conversions by good percentage points. It is all about choosing the right hammer and nail for the job.

syphilis2 8y ago

Maybe this is nonsense, but I wish I had a way to lazily load content (images) without JavaScript. The JavaScript solution is very minimal, but maybe an HTML/CSS option would also be simple.

jordache 8y ago

well some needs to create a framework around this concept. Have the build process spit out only HTML and CSS that employ these exotic strategies. It's entirely unsustainable to have a team build an app using these patterns.

kabes 8y ago

> I built the first version of Slimvoice on Angular 1 with a Node.js backend and MongoDB in 2014 (those were all the rage back then). In 2015 I decided to completely revamp the UI and redesigned and rebuilt it in React. Maybe you should make decisions based on requirements instead of hype. Oh wait: > Don't follow the hype But using less javascript is the hype today... > Plain Old HTML and CSS This section only shows some very basic UI elements (dropdown, expansion panel, ...). This isn't what libraries like react solve. > Absolutely nothing is complex about my code I wouldn't label CSS hacks with invisible checkboxes under "simple and self-explanatory code". > I found myself wishing for more innovation in the HTML spec I don't think adding even more bloat to even more web standards than a browser already has to support is the anwser.

pier25 8y ago
> But using less javascript is the hype today... I don't know, the hype is usually In React, Vue, etc.
pas 8y ago
> HTML innovation not strictly HTML, but there's a lot of interesting goodies coming down the wire: https://css-houdini.rocks https://css-houdini.rocks https://ishoudinireadyyet.com https://ishoudinireadyyet.com
MarkMyWordsMan 8y ago
kabes is to the point! It is fashionable to hate on modern front-end frameworks these days. Imagine the OP grows their platform/company, hires a bunch of devs, what a nightmare that would be to keep avoiding JS and build on the product. All so just because using JS is so mainstream, ugh.
nathan_long 8y ago
> But using less javascript is the hype today... Is it? This article on npm weekly (https://medium.com/npm-inc/npm-weekly-133-billions-of-packages-downloaded-621a5196593 https://medium.com/npm-inc/npm-weekly-133-billions-of-packag...) says 4 billion packages were downloaded in a single week - representing multiple packages per week per human on earth. (Granted, this was Feb 2018, which is 2.8 millennia ago in JavaScript years.) This site (on which you can't use the back button after choosing a graph) seems to show downloads still growing for popular packages. https://www.npmtrends.com/ https://www.npmtrends.com/

deleted 8y ago

[deleted]

honkycat 8y ago

The very-immature Phoenix LiveView kind-of fits this use case. It looks AWESOME and I'm excited to watch it mature over time. Basically, LiveView is an Elixir library that allows SPA-style web page interactivity with server-rendered pages.

jypepin 8y ago

I had fun building our wedding website without any JS just to see how much I could push the boundaries of CSS and HTML. That was fun and a good learning experience. I'll now be able to build better apps _with JS_ knowing where it makes sense to push CSS/HTML and where it makes sense to use JS. I recommend any front end engineer to go through that exercise, but it is not a good solution for real production systems.

t0astbread 8y ago

This "no-JS" movement is cool and I love CSS hacks (in production?) but I also love the component mentality these JS-frameworks provide and not having to host frontend servers (other than for static files). Are there any good "pure" solutions for that?

roywiggins 8y ago

A nice way to progressively enhance something like this is to use Intercooler.js when you do want to update only part of the page. You're still just slinging HTML back to the browser but it lets you update only part of a page without using iframes or something, and since you're just adding data-attributes to links and forms, you don't write any javascript.

slow_donkey 8y ago
I would suggest using Vue progressively at that point. Refactoring our endpoints after using intercooler was not fun and using Vue/react without going full SPA let's you move on way easier

MarkMyWordsMan 8y ago

Is it popular to hate on JS these days? Kudos to the author for creating the stuff but would you build the next Amazon.com avoiding JS? More often than not, I see Backend developers taking pride on not using JS rather than vice versa. Also, FB and GOOG aren't naive to spend enormous capital and manpower on React and Angular projects. Probably will get downvoted but just because someone writes pure C does not make him/her a better developer than someone who just writes Javascript.

x3ro 8y ago
I'm still trying to grasp why these discussions so quickly spin into extremes. The author clearly states her intent in the first paragraph: > With the new version I wanted to prove that it was possible to deliver an amazing user experience with a great design while drastically reducing the complexity of the code, maximizing reliability, and minimizing the cost to the end user. She goes on to show us what she did, where it worked and where it didn't. The most important points I take away from her article are: 1. It's quite possible to build nice-feeling (YMMV), non-single-page web-apps without (a ton of) JavaScript 2. Critically evaluate if you need the complexity that an enormous JS framework brings > You probably don't need a "Progressive Web App." Seriously evaluate if your app needs such complexity. This has nothing to do with FAANG. Nobody disputes that there are use cases where it's a really good idea to use React+Redux+Jest+Enzyme+XYZ et al. But _maybe_ (and in my personal experience, in projects significantly smaller than Amazon.com, often) you simply do not need that amount of additional complexity and challenges. It'd be so nice to just accept that the author provides an interesting data point (it can work without JS) in a community strongly biased towards starting projects by importing ~1000 node modules.
HelloNurse 8y ago
It is somewhat popular to hate on useless dung heaps of pointless Javascript, not because it's Javascript (writing complex code in a mediocre language with mediocre libraries is a separate concern), nor because backend developers have good reasons to do things in the backend, but because it's overcomplicated and so bloated that it causes performance problems, just like nested table layouts a few years ago.

ryanmarsh 8y ago

While I understand the concern about bloated frontends, I do not understand the throw-the-baby-out-with-the-bathwater mentality of JavaScript-free front-ends. Furthermore I feel like there's a misplaced sense of pastoralism or nostalgia about the-web-before-JavaScript. The fact is there was a very brief period where the World Wide Web was both widely accessible to the public and JavaScript free. I built my first website without JavaScript in 1995. By 1997 I was building incredibly interactive single page apps in IE4 with JavaScript and DHTML (as it was called at the time). By 1998 my full time job was writing cross-browser JavaScript. That's twenty years ago folks. jQuery didn't hit the scene until 2006. Why was jQuery created? Was it a revolutionary new tool that gave us the ability to create applications that heretofore had never been seen? Or, was it created to tame the horrendous mass of JavaScript that had already accumulated? We can talk about bloat, but let's be honest about what the web browser is now. Chrome is an application container. The web hasn't been purely hypertext for a long time. Back when it was we complained about the bloat... of images

Justsignedup 8y ago

It is hard to argue against using JS. I tried that no-js approach as much as possible in the past, and hated it. Using React for front-end development and keeping bundle sizes small through good build processes is amazing. I genuinely enjoy building web front-ends now because of it, where as before I avoided it like the plague.

NightlyDev 8y ago

I totally agree that js is used way too much and dependencies are often included without ever considering the consequences. But Javascript itself isn't bad. Just use it when it makes sense, and minimize it. Remove any dead code so phones won't have to spend cpu and data on it.

robmccoll 8y ago

I'm amused by the Javascript mouse tracking used to rotate the phone image on the first page.

buzzerbetrayed 8y ago
I thought the same thing. Of all the places that javascript could have been cut out, that had to be the most obvious.

ghostbrainalpha 8y ago

A website without JavaScript is like this comment.

freeopinion 8y ago

> I wanted to prove that it was possible to deliver an amazing user experience with a great design while drastically reducing the complexity of the code, maximizing reliability, and minimizing the cost to the end user. ... > The Website Obesity Problem is not getting any better for the web at large. These are both important points. But remember that 50MB of CSS stylesheets is still very obese and very complex. Replacing bloated JS with bloated CSS is of arguable value. Just saying...

anthony_doan 8y ago

There is something like that the Elixir web community is trying to do with Liveview, Texas, Morphling and Whistle. Several competing libraries doing the same thing I believe, I've only seen Texas and Liveview in action. The whole point, iirc, is to manipulate the DOM on server side and push those changes via a websocket. So the DOM manipulation is on server side and the code is server side language Elixir. There was a demo for Texas and Liveview which show pretty good performance. I'm not sure if it is good enough performance but it looks promising. Video for Texas: https://www.youtube.com/watch?v=NWgwUKfR8Xg https://www.youtube.com/watch?v=NWgwUKfR8Xg Video for LiveView: https://dockyard.com/blog/2018/09/12/liveview-project-at-elixirconf-2018 https://dockyard.com/blog/2018/09/12/liveview-project-at-eli...

mercer 8y ago
I've played around with sending html strings via Phoenix channels and using morphdom to change only what needs to be changed. I'm quite happy with the results, even when sending an entire page for every significant change, and can't wait for LiveView to be released (estimated later this month, IIRC).

erikpukinskis 8y ago

I don't see how you go from "giant JS payloads that can render your whole site are bad" to "don't use Javascript to hide a DIV". Maybe the CSS hack is faster than onclick="document.getElementById('zip-code-modal').style.display = 'none'" but it's quite likely not.

duchenne 8y ago

How do you guys achieve this in practice? I made my home page without javascript, and it is blazing fast. But as soon as I try to make something more complicated I bumped into practical problems. - Components. I want to have the same navbar on all my pages, but I don't want an un-maintainable copy-pasted code on all my pages. - Data. I need to display some data that is different for each user. How do I embed it in my webpage without ajax calls? - Dev tools. I need debugging / bundler / source maps. Some possible solutions could be: - PHP. It has components through "require". You can embed the data easily. But, I do not know good dev tools: If I debug the javascript in the chrome dev tools, can I edit directly the php script? Can I minify/babel the output of the php code? And I cannot use the same php code on both front-end and back-end. - Vue-SSR. Nice one-file components. Data can be provided within express. I can re-use the same code on the front-end. I have not tried yet, but it seems very interesting. - EJS. It has require and data from express. It is very simple too use. But the tooling is lacking: no source map.

cfv 8y ago
Just a stupid question. Why would you need a bundler for plain HTML? I agree on everything else, but I kinda tripped on that and I'm not sure what you're actually looking for.
- duchenne 8y ago
  If you have a solution to avoid using a bundler altogether, that would be great. Personally, I would use it for: - compression of html/css/images. - css compatibility with old browsers. - source map / auto-refresh during development. - For any even slightly complicated app, you still need at least a bit of javascript. So, you need babel, minification, source maps, and so on...
pdimitar 8y ago
Err, isn't everything you are worried about also served quite well by all server-side rendering frameworks since forever? I legitimately cannot understand your issue.
- 8y ago

cfv 8y ago

So I decided to try and figure out this specific trick about toggling content and how well this would actually work in, say, a tab panel. I mean, it is a cute trick right? I made this: https://jsfiddle.net/sr8z1mob/6/ https://jsfiddle.net/sr8z1mob/6/ Yes, it is a cute trick. Yes, it CAN be made more accessible, and kinda sorta avoids the most obvious problems with like tabindexes and so on, although it did take a lot of work on my end for such an insignificant demonstrator, and I can't still set the active tab by hand in any way in here. Which is a rather important cue about it's capabilities. There's other things I cannot do: - Use this as an actual component! I would have to set up an editor expansion to type all this stuff each time I wanted a tablist, and I cannot globally modify how all of them work. Making this into some kind of custom tag would be GREAT, but it could also probably mean going back to .htc files which is not so great. - Track user interaction! It's important to us to know what the user is doing with our product so we can make it better. - Auto-select the first tab's content in all tablists without contorting my brain into a cramp - Load the tab contents lazily. Maybe you don't need the King James Bible (replace with any other long blob you like) loaded in there by default, just when you actually want to go look at the thing. - Skin the scrollbar easily (OSX for instance is a major PITA I'd like to have auto-solved for me) - Tell the server when the tab was scrolled to the bottom - Did I mention I cannot mark the current tab as open in any real meaningful way? This is a fun experiment. But really, it all boils down to requirements and development times. Do you have the time and energy to spare to twist the browser into doing this kind of things? That's awesome! I, more often than not, don't. That's sort of the reason why we use a development framework that puts us into a mindset we can work better with to cover more ellaborate scenarios (like being able to mark the currently open tab as exactly that without having to think about doing it).

ritty 8y ago

I admit it, I hate single page apps. I see very few that actually work well. I don't hate JavaScript, it has its place, but you don't need to make an entire website an SPA. Stuff like the main Spotify, Slack, or Discord pages, and even things like Google Docs, and email front ends are fine for SPA. But you don't need to also embed all the FAQs and other crap into the SPA. You know what isn't an SPA? Hacker News. You know what else isn't? Google, GitHub, Amazon, and Stack Overflow. I've disabled the SPA version of Reddit. I've built SPAs and they are so much harder and take so much longer to develop and maintain than traditional web sites. I wish they'd just die. Sadly, everyone else at my work orgasms about SPAs, pushing every damn thing into it. We have stuff that works perfectly well and no one has ever complained about it? Screw it, let's spend $50k turning that feature into an SPA. I know many of you disagree with me and I'll get off my soap box now. </vent>

masswerk 8y ago

Last year, I relaunched my website with just CSS – and I'm not missing anything. JS is used just for the error pages, featuring a game as optional content. :-)

RobKohr 8y ago

I think this ignores one of the main benefits of JS based page rendering. In the days where I worked on PHP apps, all rendering was done on the server, and that came at a great cost regarding server side processing and the complexities of peak load times, along with some pretty hairy test cases. With everything rendered in js, you are mostly just transferring static assets, so the browsers are doing the heavy lifting for you. The only things that end up taking up server CPU cycles and system memory were API calls that are easy to test, debug, and optimize. Also, those API calls can be cached, and become static assets for high traffic apis such as ones accessed on the front end. If you do it all on the backend, you are doing all the rendering work, and it is hard to split off and optimize processing time for things. Finally, for testing, it is really easy to unit test an API, and for javascript frontend work, there doesn't seem to be the code regression type bugs that are so time consuming, but when you mix the data api stuff with the front end rendering, unit testing becomes a big mess. Bloat needs to be thought about, especially for limiting bandwidth, but just for curiosity, I checked out my own website which was using React and a bunch of libraries, and it was only 500K. This is about half the size of the banner image on that article. Some libraries are much larger than React, but going JS free and losing the power React gives you doesn't seem like a good trade off. Of course if you get some happys from being an ultra-purist, then I get that, and that is priceless. From a practical perspective though, this seems misguided.