171–180 of 215 posts
Maybe the CSS hack is faster than onclick="document.getElementById('zip-code-modal').style.display = 'none'" but it's quite likely not.
Earlier quoted context omitted.
But why should he put time into supporting you?
Why should I use his app?
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).
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. Pl…
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 ar…
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 wri…
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
Earlier quoted context omitted.
Why should I use his app?
You don't have to use his app, and he doesn't have to support users like you. 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.
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"!
>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. 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.
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,…
The whole thing is a solved problem. You can easily render React apps on the server and send HTML down the wire, then lazy load the rest of the JS. Author could have installed next.js and called it a day. 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…
Earlier quoted context omitted.
I've seen pure server based applications neglect all of those things, including destroying your input on errors, so it's not really helpful for anyone who actually needs an SPA.
Yep, how many times have you seen a web page say tell you not to refresh the page to avoid losing your progress.
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.
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).