No I haven’t - I actually chose the browser that requires the least number of alterations for it to work the way I want it to. In fact the only customisations I have applied are ones that have no impact whatever on web pages as whenever I have problems with a web page I try turiing off all the customisations to see if they have any effect. I have never found a case where a site works with the customisations I have applied turned off but doesn’t work with them on.
All of the sites I have found that are broken are broken even when I restore the browser to its default settings. A few of the broken ones are fixed if I apply my customisations but there are none where the customisations break the site.
Since the sites are broken when I run my browser with its default settings it can’t possibly be my fault that the sites are broken.
Needing to turn off JavaScript temporarily never happened to me before this site switched to using Discourse. Now I need to turn it off whenever I want to copy/paste as Discourse blocks the copy function in my current version browser.
Not a very realistic analogy. A better one might be what’s happened to modern cars. Not so long ago, computers started to appear in cars, offering some handy extra functionality … but without the car entirely depending on the computer. (Or at least, you could still work on the car yourself if you needed to.) These days, practically everything in the car is dependent on the computer, which is kind of a walled garden to the car enthusiast who wants to tinker when something has gone wrong. It’s an unnecessary and regrettable turn of events that to get your car fixed now you have to turn to a manufacturer.
So what have we gained by cars being totally dependent on a computer? We know that cars can work perfectly well without one, because they did for a century. But when things went wrong, you could get yourself out of a fix (by roll starting or whatever). In modern cars, when something goes wrong, the car is pretty much a useless lump. Of course, the manufacturers will rub their hands together, because you are dependent on them to fix the car. But who else benefits from this?
How do end users really benefit from sites that are JS-dependent? OK, you get to avoid page refreshes. Big deal!
I have one that adds a ‘view source’ link to all web pages so I can assist people with their web page problems even if they have some of the regular ways to view source blocked.
I have one that disables the debugging calls - alert() and confirm() [prompt() is comment out as too many people still misuse this one]
I have one that displays the alt text of images in the tooltip after the tooltip text so I can see what would be displayed if images were turned off
I have one that asks for confirmation before running flash
I have one that fixes a bug on another forum that I visit
Of these five I wrote the first three (which are less than ten lines of code between them), the fourth is a standard script available for the browser I am using and the fifth was written by another user on that forum (and that script only runs when I am on that forum site)
None of these should have any impact on how any sites function and I have never come across a case of any of them breaking site functioning.
I have however come across many sites where the way they are coded breaks the regular functioning of my browser - eg. the way that this site blocks my ability to copy/paste unless I turn JavaScript off temporarily while doing so - which indicates a bug in the JavaScript of the site.
The fact that my car has almost 300hp, but is just an average mid sized car, it doesn’t get 5mpg, and I was able to drive it from the dry plains in TX to Denver (the mile high city) and on into The Rockies without it breaking down or really even taking notice that I was going up in elevation.
I remember driving through the Rockies as a kid. It was not fun and we were topping out at about 15mph at ultra high RPMs.
The same system that controls this, also helps keep the car from breaking down constantly by making sure it’s always operating at optimal air/fuel, which helps to reduce temperature damage to the inside of engines. The fact that cars can easily go over 100,000 miles can be mostly attributed to the Computer.
Not to mention, computers also help control the sophisticated air-bag systems we have in cars today, which save millions of lives ever year. Have you ever seen a crash test between a car from the 70’s and one from the 2010’s? If not, you should find a few and watch them.
There’s probably a lot of other things the computers in cars do. I actually don’t know much about cars.
It is a big deal for data and interaction heavy web applications that perform significantly faster over traditional some might say *antiquated web sites. I would agree though that for some websites it doesn’t make sense to take this approach but for anything that is a web application it does. It makes a whole lot of sense. I think it is pretty short sighted to still promote the same way we have been doing things for nearly 20 years time. JavaScript frameworks that work off a rest server are the future and everyone is adopting the pattern for building web applications. You are either going to need to get onboard or soon enough become obsolete or stuck working on useless, rinky dink sites. Not to mention on mobile devices a single page application is highly capable of providing an experience nearly equal to that of a real app. Form a UX perspective that is a huge win.
I see that this is still on-going. I have yet to see a thread where a PRO-Javascript (Using Javascript as car engine) and ANTI-Javascript(Using Javascript as a window washer solution) agreed on anything. So, it’s pointless to prove each other is the better solution. Just state your opinion and move on to next thread.
(I haven’t read all responses, yet, so if this reflects what someone else has already said, my apologies)
Not to mention that a certain browser has removed the selection for disabling JavaScript from the user interface, forcing said user to go into “about:config” to do it.
Blame employers. They are too quick to add all of these flashy buzzwords for new technologies and JS-based frameworks to their job reqs so all of us engineers are in a constant mad scramble to learn these new buzzwords. And since there’s no better way to learn than by doing we try to work them into our current projects be they personal or professional so we have some tangible learning and also proof that we’ve done that and have it in our portfolios. If employers weren’t tossing the new technology buzzwords around (even though 90% of the time I’ve interviewed for such positions they are only interested in the framework, not actually using it) I think a lot more developers and engineers would feel less impetus to shoehorn these flashy new boondoggles into sites they’re working on.
That being said, I’m in the industry myself and I feel and understand the pressure. I have built entire sites using client-side hydration with “single page view” loaded with XHS requests for everything and complex client-side data management just because I needed to have doing that in my portfolio. There was absolutely no need in the project to do it that way but I wanted to show off some Angular chops and that was a quick and dirty way to get some experience and toss something in my portfolio.
None of these new technologies are really radical or difficult to pick up and use (that’s the whole point of them), so I think it’s really unrealistic that employers absolutely grill job candidates on these things. If you’re a solid full-stack coder or even a solid client-side developer and can prove you understand the basics then all of these frameworks just become convenience extensions in the right case at the right time. Employers need to keep that in mind, I think. They need to relax the artificial demand for industry buzzwords which puts us developers in a panic to prove we know the latest and greatest boondoggle of the month.
Can’t just blame them. I’ve worked in enough shops that the developers pushed for new technology just because they wanted to play in the new toys.
One shop went from .net to php running Symfony and interfacing with Drupal simply because one (and only one) developer wanted to play with them. Didn’t matter that no one had any experience working with php, Symfony or Drupal. And we were in a ridiculously small timeframe without well defined requirements. Needless to say, it wasn’t fun…
Can I just point out: Progressive Enhancement is NOT about whether users have JavaScript switched off. It’s about getting sites/apps to work on every device. The web is device agnostic and, with PE, your site can be used in Chrome 42, Microsoft Edge, IE1, Lynx, Opera Mini, the Google indexing bot, screen readers, ebook readers etc. As long as the device can download HTML, it’ll work. That is a good thing.
PE doesn’t mean functionality and effects are removed or simplified. It means you add them for browsers with support. And it’s not significant additional work of you do it right from the start. The only people saying PE is too much effort are those who don’t do it.
Perhaps you don’t care about wide coverage? Perhaps you expect your app to die within a matter of years? Fine: develop using a client-side framework and slap a “best viewed in Chrome” logo on the front. But be aware you’re developing using web technologies: you’re not developing for the web. You’re blocking a section of the community. That could be search engines. That could be potential buyers. That could be those with motor or visual imparements. There may be legality, profitibility or future-proofability(?!) consequences.
To me though, it’s just about doing the right thing. You shouldn’t care about who’s using your site or what device they’re using. Everyone is welcome.
I agree with everything you’re saying there, about Progressive Enhancement, and device agnosticism (to a point - we can’t help it if people create really stupid browsers that are overly limited in capabilities, or insist on using browsers that are, then they may get the inferior experience and complain; but that’s not the developer’s fault, as at least it works).
However, I still feel like there are cases where considering support for IE1 or Netscape or the Internet Browser on my Kindle Paperwhite or whatever the crap we’re discussing are just… irrelevant. I’m sorry if that’s a point of contention, but… that’s just how it is. If people choose to make what are basically ridiculous decisions about what they use to browse the Internet, then I guess they’ll be frustrated.
You shouldn’t care about who’s using your site or what device they’re using. Everyone is welcome.
That is simply not true. There are countless web applications designed for particular groups which are not welcoming everyone. I’ll point you, to start with, to a company intranet.
Everyone is not welcome and it’s in a very software controlled environment, in some cases, to boot.
Now, do I think it should work on multiple browsers? For sure. I 100% agree with that. But is your actual argument valid here? No.
And you definitely should care. Having information and using it to make informed decisions isn’t bad; it’s good. And the general idea that we shouldn’t care who’s using a site is even more crazy! Have you ever heard of marketing at all?
TL;DR - I like the idea of PE in general. I love the idea of it for use on much of the web. But I don’t find a need for it across the board, and I find the idea that we shouldn’t care who uses our apps to be absurd.
I think the problem (if it’s right to call it a problem) is that web applications are getting closer to looking and behaving like desktop applications, and desktop-like applications don’t decompose well into static pages. It takes more work on the server-side because you’ll need to create page views that only the non-JavaScripters will need. And it takes more work on the client-side because we don’t even have static content to enhance anymore; we have templates from which we generate dynamic content.
If we happen to be building a more traditional kind of website, then certainly use PE. But if we’re building a desktop-like application, then sometimes we just have to accept that JavaScript is required for the thing to work.
That’s not entirely true. First thing that comes to mind are the fact that CSS :hover doesn’t work in IE6 and some of the older mobile browsers have problems with persisting them.
Do you use CSS3 or HTML5? If this is truly the case and you try to make things as agnostic as possible, I don’t think JavaScript should even be a consideration. If you want to get into compatibility problems, then JavaScript has been used historically for 2 things: 1) Tacky Effects 2) Fixing Compatibility & Display issues across browsers, devices, and screens.
It may work. But if it’s an app, the user probably won’t know how to use it without CSS or JavaScript. I can’t speak for anyone else, but I’ve always been in favor of content based sites not to be reliant on anything but the HTML.
Actually, I build for the opposite. I don’t see what developing in a client side framework has to do with that. Backwards compatibility is going to be around for at least as long as support and it’s a heck of a lot easier to support apps built under old outdated frameworks, than it is trying to figure out what that specific developer decided to do. If you’re not pulling off a CDN, which you can’t do if you build for longevity, then it doesn’t matter what happens in 5, 10, 15 years as long as you have minimal support.
Of course they won’t get the same experience. But neither will those using screen readers. Are you saying they should be abandoned just because their technology is old or different to yours?
An Intranet is not the web. It’s closed. Use whatever you like. That said, I would make the point most large corporations use browsers such as IE6/7/8. PE will prevent you going mad in those environments!
I totally agree that some apps need JS. Consider Google Maps: it’s impractical to build a server-only version (although Google has a separate application to do it). But those applications are relatively rare.
CSS is a great example of PE! So :hover doesn’t work in old browsers. Why is that a problem? If you’re relying on it for something such as a menu there are plenty of ways to get around it.
Posssibly but it seems we haven’t learned from history. I thought the bad old days of “best viewed with…” were over but it’s happening again.
I think that’s the main issue here. When does a web system become an ‘app’ for which JS is essential? When you have a hammer, everything looks like a nail.
I know this is a minor point, but that’s not really correct. Hover always worked in IE6, it just had a few edge-case bugs, as I describe in one of my really old articles on Smashing Mag. But that is kind of beside the point, so I’m just being a nitpicky troll.
