You might not need JavaScript
51–60 of 254 posts
Re: You might not need JavaScript
#52Many of these make sense, but a few (for eg. 'View Switcher') end up obscuring the logic of what's happening, and are probably better off done in JS.
The image slider for example can't be paused. There's the CSS property "animation-play-state" which could have been used to do this, but that literally freezes the animation, whereas you typically don't care about the animation but don't want the slider to move on to the next image (i.e. finish the transition, then pause).
And of course depending on which browsers you're targetting, many of these are horrendously broken for most of your users.
Re: You might not need JavaScript
#53The site makes no claims as such, but it undermines its own credibility if it uses .js files. Surely they could have figured a way to do without them.
Re: You might not need JavaScript
#54The validation examples and input types are a case in point. Even on browsers where they work, the alerts can't be styled and the behaviors can't be controlled.
Re: You might not need JavaScript
#55Re: You might not need JavaScript
#56I've never heard somebody say that. Can you elaborate?
Re: You might not need JavaScript
#57You might not, but you probably do. The validation examples and input types are a case in point. Even on browsers where they work, the alerts can't be styled and the behaviors can't be controlled.
It's not clear to me whether that's a problem. Isn't consistent UI a good thing? Isn't it faster to fill the forms correctly if alerts always appear in the same way?
Re: You might not need JavaScript
#58Some of these are cool examples. Others, like the modal, won't scale very well because now you can trigger modals by tabbing (breaks keyboard navigation) or most of the form examples as you'll likely hit many endpoints that require JSON (which yeah I know "you're making a web app why can't your endpoints accept a form?" but as we all know it's never that simple and you might want to provide different behaviors for, say, showing a progress bar or disabling certain features during the submissions or a THOUSAND other things).
I get axing dependencies. I really do. I wrote msngr.js entirely in ECMAScript 5 using zero dependencies so I'd have the most flexibility possible. But at the same time overcomplicating your code to the point where it's breaking standard practices or making it un-maintainable simply to axe a dependency is the wrong way to go.
But by all means keep making cool stuff that shows off how versatile CSS is! Just don't expect to use all the CSS tricks you learn in a production environment.
Re: You might not need JavaScript
#59Since half the examples do not work on Safari, I believe the title is a bit misleading.
Safari is the new IE6, stop supporting it and let it die. It will not get any better anyway. If most of your users are on iOS, then make an app for them, it's what Apple also want you to do...
I can only assume you never went through the pain that IE6 delivered... It has been some years now but I still get nightmares about it. It literally made me question at one time if I didn't made the wrong choice to focus on web development.
Apple may be dragging its feet when adapting new api stuff, but the situation is by no means comparable as what the situation was with IE6. Not by a million miles.
Re: You might not need JavaScript
#60Earlier quoted context omitted.
Safari is the new IE6, stop supporting it and let it die. It will not get any better anyway. If most of your users are on iOS, then make an app for them, it's what Apple also want you to do...
> Safari is the new IE6, stop supporting it and let it die. Not sure what old wives tales you have heard, but actually Safari was the first browser to 100% support ES6. And compared to Chrome, it uses 1/3 less battery...
- Apple didn't attend EdgeConf 2015
- https://webkit.org/blog/ was not updated often enough
- Safari 9 had a seriously buggy IndexedDB (fixed in Safari 10)