A JavaScript-Free Front End
dev.to
dev.to
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.
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.
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/) ticked a lot of boxes last time I checked.
The same can be said about any JS library that interacts with page controls.
The wast majority of modal dialog implementations on the web do no follow the standards you're referencing. Do you routinely criticize websites on this basis, or is this criticism only reserved for ones that use vanilla HTML+CSS for core functionality?
>More specifically, no you cannot add keyboard shortcuts "with 0 rework".
Yes, you can. 0 rework != 0 work. Anything that unchecks that checkbox on Esc will close the modal. To implement that you don't need to change the structure of what you've already done. Progressive enhancement.
>How are you returning the users focus to the active element before they opened the modal?
Focus management has absolutely nothing to do with where the state of the modal is stored. You can implement all of the usability features you want on top of Checkbox + CSS solution with the added benefit of not screwing everyone who can't run your scripts or completely breaking the website for everybody if something in your JS gets broken.
Difference being JS, if written by an averagely competent individual, can be changed once and this change will apply to any instances where it's called, and this cute pattern will need to be manually updated in any number of places where it's applied, one by one.
> Yes, you can. 0 rework != 0 work.
Rework meaning you have to go back over the "done" thing and then do more to cover the technical debt. On each and every instance of the thing.
> if something in your JS gets broken
As opposed to replacing the cute styling trickery for browsers that don't really support it, which is somehow better?
What is the case for making Javascript-blocking users a priority?
It's a two-way thing: many developers don't want to support people that switch off JavaScript, and these consumers are apparently happy that they can't access the majority of the internet (or so they say).
That said, aside differing biases I'm not convinced that we actually disagree.
The answers actually pretty simple. People who are interested enough in technology to read hacker news are both disproportionately likely to discover a new product trying to build an audience, and disproportionately likely to influence their friends either for or against that product. They're trusted by their non-technological peers.
So why support script-blocking hacker-news users? Because if your website doesn't work for them, they're gonna tell all their friends that your product doesn't work properly. When I got my first job, I was told that on average satisfied customers tell 2 friends they were satisfied, and dissatisfied customers tell 12 friends they were dissatisfied. I don't know how accurate those stats are, but I do know people complain more than they praise.
I certainly go out of my way to warn friends and family away from products that I feel are committing technical faux pas. How else will they know they're using websites made by people of limited technical capability, with all the risks that implies, if I don't tell them?
Can I sue you if your website serves me malware? Because that's the concern.
If you're hotlinking them, I don't trust you.
I rarely feel that website owners out out to get me, my distrust comes from scripts that load scripts that load scripts. Lets not piss about, I know most people who have written websites that are loading jquery from a remote CDN haven't bothered to inspect it to see what it's loading. By contrast, a website that has vendored all it's script dependencies has looked at the entire dependency tree at least /once/. That shows a baseline level of competence that I'm willing to extend trust on top of.
How do you properly shift focus to the dropdown menu whose visibility is toggled by clever CSS tricks?
And yes, modals may be needed sometimes especially in payment forms even if that modal is only visible to the screen reader.
How did we even get here? I remember when we used to hide javascript inside of comments to support user agents that didn't speak it.
Then there's "semantic HTML(5)" (`<article>, <section>`, etc.), which still exists, but is not _particularly_ worthwhile for accessibility: Too much of the web lacks these tags, so most common consumers of this nature (scrapers, screen readers, content summarizers) use other, often AI-based, strategies to tag content semantics.
On the other side, there are more solutions built into HTML and CSS one thinks. In your particular example, you can use the HTML dialog element and get built in keyboard and focus management (still requires a polyfill for many browsers).
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.
Everything is a tradeoff.
Assuming you aren't one of the sites that thinks it's appropriate to require `DOOM.WAD`, it can work out well.
> it drops every 10th request
If the app saves data to a server, that's gonna happen regardless anyways (and one could argue that techniques like optimistic updates might make the experience even worse)
Also remember that HTML can be streamed and partially rendered even if it's not fully downloaded, and the investment required to enable this is minimal. The same cannot be said about a SPA's data fetching/rendering strategies.
Having worked on bloated apps before, I despise when people throw around the word "prefetching" as if it's some sort of magic spell. At best it eats my battery and bandwidth needlessly, and at worst, it's weasel wording for slowing down time-to-first-pixel :(
I think that's pretty damn good; to solve the 2 second latency, I think the developer is better off using a CDN or Netlify's ADN so that your site is delivered from a server closer to the user.
Terrible connections exist. But I fail to see how adding more scripting will always help with that. Service workers are definitely promising, but documentation for common use cases is still lacking.
Even with a terrible connection, I would still trust a server-side app to load correctly on a refresh more than a SPA.
If anything, the minimal use of Javascript is as inclusive as a web app can be.
Your app has no control over browser connection management. JavaScript you write is aware of idempotency and retry semantics of your app, so it can manage requests more intelligently than the browser, without disrupting the user experience.
So sure, it won't always help if you do it badly, I can see how it always helps if you do it well.
That said, even though the way service workers are registered is sort of odd, they're pretty trivial to work with once you're there. As far as resources go, MDN is always pretty solid, and this post (https://developers.google.com/web/fundamentals/primers/servi...) on Google's web dev guides is what I used to familiarize myself with them.
Then I would have waited too long to load the page the first time and give up.
Not enough developers build this way yet though because it's quite hard work. In my opinion the answer is to use what browsers are capable of; it should not be to ignore the browser and do as much as possible on the server.
Who has good heuristics for retry (or other techniques) to achieve reliable communications for a PWA?
We do retries, with a few different strategies, but we have a poor idea of exactly how effective (or not) our retries are. Also my code for this is ugly and it's a nasty area to test properly...
I often work on a train over a 4G connection, so this describes me too. I much prefer traditional style web applications over SPAs specifically because of this.
You know what happens if a request is taking too long or fails with a traditional web app? I hit reload and it retries.
You know what happens if the same thing happens with most SPAs? It throws away my unsaved data and puts me back on the starting screen.
Sometimes there's a JavaScript-powered retry I can use instead. Sometimes it works, usually it is very unreliable (if something has failed to load, often the JavaScript is having problems too).
Sure, I'm willing to accept the possibility that an SPA can be written in such a manner as to compensate for this hostile environment. It's just: I've used a lot of these apps, and I haven't found one that works reliably over a poor connection yet.
This is just bad design though. Obviously the dust isn't settled on the whole html5 technology yet, but for anyone who is wondering how to make an SPA more resilient to network instability, the solutions are: axios-retry, idempoteny PATCH/PUT, service workers, basic error handling, and always have the URL represent where the user is.
Thing is, you get proper error messages, the ability to retry, warnings if you're about to repeat an unsafe operation etc out of the box if you don't use a SPA and render things server-side. The browser does this for you.
Sure, you can do a better job. But I've lost count of the number of SPAs and JS-driven apps where connection error = infinite spinning loader icon and no feedback or ability to retry. If you're going to willingly throw away the routing you get from HTTP, the progress indicators you get from actual links and non-AJAX requests and the browser error handling you better make damn sure you implement it all again in JS and provide feature parity for the user.
It's not just HTTP either - accessibility features like keyboard navigation often aren't implemented in React components because folks only write an `onClick` handler. Sure - the devs should've loaded "eslint-plugin-jsx-a11y " and enforced rules that prevent this sloppiness on their CI - but it's far too easy to do it wrong and so devs do do it wrong and the users suffer from a poor experience as a result.
I have an opinion too. But my opinion and your opinion really are moot.
Because do you know whose opinion is probably backed by the most data and the most expertise? Google’s Gmail team.
And Google, with all its amazing developers, who are arguably at the forefront of javascript standards and general web app innovation, and who have literal billions of visits, they have made the decision to give you a link and tells you to use a basic, server-side rendered web app if you have a “slow connection.” And they do this while attempting to boot up all the PWA/SPA framing of the main app, just in case, I don’t know, all that stuff fails.
So I think I’m going to give Gmails opinion a lot of weight here
I completely agree with the point you're making though; if a user is on a low bandwidth connection then sending as little data as possible is best, and that's likely to be plain HTML with very little rich content like images.
That said, Gmail's slow connection UI is horrible to actually use. Very few people choose it over normal Gmail. Most people want the big fancy app, so we as developers should work out the best way to deliver that.
This is a unicorn. If it's the real world we're talking about, as far as I can tell client-heavy webapps that are actually engineered this well -- and don't frequently end up in a more inscrutable state than a pageload failure when network issues rear up -- are rare enough in practice that it feels weird to hold that up as the yardstick for criticism.
And if the point is that more applications should get there, well, that's more or less orthogonal to the point of the article, which (in spite of the headline) isn't so much that no one should use JS for anything ever (since the author details the JS he made a thoughtful choice to include), but that a notable range of UI behaviors that are frequently implemented using JS without a second thought don't necessarily have to be, and there are plausible benefits to the alternative. So this isn't exclusive with background loading / prefetching.
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".
I think it’s an appropriate response to blanket advice on choice of tech stacks.
I was on a team recently that only wanted to do Rails apps. They only wanted to make monolithic apps. Any mention of a more modular design would be met with derision. I don’t think this attitude is unique, though. And it’s really hard to overcome and see balance when the entire team clearly has no interest in changing or updating their skill set.
If you put your app logic in something like Redux it'll work on server-side rendering, client-side rendering, and can be included in react-native down the line.
In the time the author re-wrote his app, I could have gotten the same benefits with SSR and ported it to react native. But yeah, javascript bad REEEE
Are you saying that rhetorically? In my experience, React is no silver bullet (e.g. different router and styling mechanisms for RN), trickiness dealing w/ timezones in SSR, etc.
And besides, the point here was largely about bundle size and fast time-to-interactive. Next.js optimizes a lot for developer experience, but you're definitely still going to be shipping a pretty sizeable JS bundle with slower characteristics than a hand-coded "closer-to-the-metal" thing.
No.
> And besides, the point here was largely about bundle size and fast time-to-interactive.
As long as the point wasn't to be productive I'll just mind my own business.
Not a day, but probably a week of debugging. Each and every suggestion you made in your comment makes the deliverable tremendously more complex, is very expensive, will need ongoing maintenance, and is ultimately not needed.
Javascript apps are tremendously complex, why would do this if you don't have to?
If you already know Rails I'd say use that. If you only knew ruby then reaching for rails would be overkill. But if your business requirements need the features of Rails, learn rails instead of rolling your own framework..
I thought people use Rails mainly because they like it or are thrown into a team that already uses it.
I'd be fine to just use Rails for something like that since I'm quite familiar with Rails, but I would never recommend it to someone who doesn't know it.
The author is clearly experienced in UI development. The app was already written in React/Redux. So honestly, yeah, just install next.js and fix your routes.
This solution would be a complete non starter for any professional project in terms of accessibility - there's a few issues screen readers would run into with this. Not only that, but good luck getting other developers to sift through your spaghetti code.
But the main thing is, the authors goals are somewhat pointless. If you don't want a SPA then just use jQuery. The author ended up using plugins anyways so the whole story was aimed at people who don't know front-end but latch onto this idea of javascript is baaad. Don't be that guy.
So to recap. If you don't know javascript, and you don't want to learn the standard tooling - please don't roll your own framework and blog about it.
Edit: looks like someone already commented this on his blog. This is all you need to know: https://dev.to/isfotis/comment/9c7k
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.
I don't know, the hype is usually In React, Vue, etc.
not strictly HTML, but there's a lot of interesting goodies coming down the wire:
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.
Is it? This article on npm weekly (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/
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-fastes...
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.
Good examples are, well, almost any modern and popular app. Like Trello for example. Users spend lots of time on the same page making micro-interactions, creating cards, moving cards around, adding tags, etc. You want to make the in-app experience as flawless as possible in these types of apps, and the initial JS size doesn't matter so much especially when it's cached. There's also lots of shared state and you might be saving multiple things on the server at the same time or uploading multiple files in the background while editing other parts. You might want to store data offline and sync later to the server. Once you have decent complexity, JS app with framework such as React help a lot.
I'd use websockets if that was an issue. That said, Trello is a good example where I do agree a web app is a great solution.
In other words, when the web is architected as intended, it works fine, even with javascript.
Imagine that. It's like the problem isn't javascript per se, but unnecessary complexity.
Thanks and keep up the good fight.
Was this intentional? It gave me a bit of a chuckle.
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
[1] https://m.signalvnoise.com/stimulus-1-0-a-modest-javascript-...
It's got a badge and everything.
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.
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.
I agree on everything else, but I kinda tripped on that and I'm not sure what you're actually looking 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...
I legitimately cannot understand your issue.
Which SSR framework do you prefer?
Solutions
Use a templating engine with a backend language. My goto is jinja. For example you create a nav template and then include that template in your larger templates. You can then render different templates depending on the given route or file.
Alternatively use a static site generator. I use pelican. The static files are generated upon deployment from markdown for content, scss for css, templates for html, etc. There are plugins for using minifiers.
For user specific data, You can give the user a randomly generated session id cookie generated via a backend language. The backend language generates further pages based on information retrieved from the session id cookie. The session id would correspond to state in some database. Async data loading cannot happen without client side javascript.
- Dev tools: Write tests. the backend language would have developer tools such as a debugger. Generally you can run a dev server which allows to to drop a breakpoint upon failure. (backend frameworks can support this) Alternatively, you can change the rendered HTML via a debug flag (for local testing).
For PHP, The HTTP server serves the rendered files from the backend language's application server / module therefore you normally wouldn't be able to directly edit the backend code via a web browser.
It's pretty new, but: 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.
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.
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.
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...
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
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
Video for LiveView: https://dockyard.com/blog/2018/09/12/liveview-project-at-eli...
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.
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.
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
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.
No one seems to get that the C++ still works and in nearly all cases is faster, compiles very fast and is very quick to develop with now that everyone has shared their code and since functional algos have been added to the stl. This all happens with the memory safety people require since we have shared and unique pointers and Intel's thread building blocks. My fully featured application is 3.7 MB and takes 12-15 MB of ram to run and handles 100k+ requests per second from my laptop. Those stats aren't even that good with the exception of the rps.
If going fully native isn't your game then how about nginx with the plethora of 3rd party modules that are supplied by other developers? Maybe you just really like js? Maybe js isn't the best but you're going to use it anyway because you know it and other people have already written a lot of your code for you? Maybe you just feel like wasting money on more machines instead of one vps instance and a cache-everything cdn?
You do you I guess.
I just said that JS isn't so bad, and that language snobbery is worse when it means you're far less productive.
Use the tool / language that makes the most sense for your problem.
Assembly language backends on the other hand absolutely scream.
And with a modern IDE they're a joy to develop.
"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.
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.
> 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.
...
> 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...
I recommend any front end engineer to go through that exercise, but it is not a good solution for real production systems.
https://caniuse.com/#feat=details
And here I thought Edge was a modern browser.
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.
but there are a lot of use cases where js is essential.
it all comes down to what you’re building.
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!).
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).
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.
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>.
Maybe the CSS hack is faster than onclick="document.getElementById('zip-code-modal').style.display = 'none'" but it's quite likely not.
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.
Does anyone know of a good book on intermediate/advanced CSS to help avoid excess JS usage/complexity?
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.
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.
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.
https://www.packtpub.com/web-development/professional-css3
https://www.amazon.com/CSS-Secrets-Solutions-Everyday-Proble...
Of course, then you need a full page reload every time you edit something.
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.
That did bump up conversions by good percentage points. It is all about choosing the right hammer and nail for the job.
It's entirely unsustainable to have a team build an app using these patterns.
- 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.
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
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.
To me, this whole thing about JS-Free is a backlash against overdoing things in JS, and it's as good time as any to rethink today's status quo, especially in regards to how many babies we have thrown out w/ the bath water when adopting JS-first technologies.