131–140 of 215 posts
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.
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.
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!).
Earlier quoted context omitted.
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.
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.
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 .
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
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…
> 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. 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 hap…
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.
"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/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. Se…
Earlier quoted context omitted.
> 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. 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 hap…
> 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. 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,…
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 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…
not strictly HTML, but there's a lot of interesting goodies coming down the wire:
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…