He actually had IE6 dropdowns as his example. I told him that they actually ARE possible (CSS only, yes!), just not in the conventional way.
He then edited his post. He forgot to mention it’s not readily available on most elements, but it does work.
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?
That depends, as I feel like I continue saying to people who can’t seem to understand, on the application! For informational websites? I think it’d be frustrating to not be screen reader capable, or to have content at least available in text format, even if the UI is butchered. For many interactive applications, though, they’re essentially built as visual things that can’t be effectively reproduced with screen readers at all. You can’t simply run around making generalizations about what people have to or should do without looking at their use case.
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!
What makes an application a closed environment and not “the web” according to you? What if my example is an extranet? How about any application within which the majority of the content requires you to be signed in? Facebook? The task manager I use? Google apps? Are those things not built using web technologies, by web developers, and part of the web, by your definition? They could all, in theory,have particular requirements depending on what their application does (those are random examples of the countless ones, please see the broader picture) and particular markets / user statistics that make them support or not support some thing or another, or require some technology or another.
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.
For what it’s worth, I use a combination of the latest Chrome, FF, and IE11, primarily Chrome, and I have literally never that I can recall run into a situation where a site/app that I used was requiring one particular browser - excepting old corporate crap that required ActiveX and IE only. Maybe the best solution for browser choices here is simply “keep with the times”.
I think that’s the main issue here. When does a web system become an ‘app’ for which JS is essential?
Excellent question.
ok lol… that’s pretty confusing. Anyhow, like I said, it was kind of beside the point and I haven’t read this entire thread, it’s gotten really long!
1 Like
that’s pretty confusing
it was kind of beside the point
it’s gotten really long
All sentiments that describe most of this thread, in one way or another 
Exactly! That’s an excellent argument for using PE and writing device-agnostic code!
You said it was an intranet? You’d know every user and what devices/browsers they’re using. That’s not the case for public services even if they’re behind a login.
Great! Let’s use pointer events: it has good cross-browser support. Except for Safari. But who cares - that’s only used by 5% of the desktop market and Apple should “keep with the times”!
The point is that PE allows you to use modern technologies without waiting for others to catch up. Why is that a problem?
If you develop for a subset of browsers, only people with those browsers will use your site. Those who can’t use it will disappear from your audience and statistics. They rarely complain - they just go elsewhere.
PE allows you to develop for the web - not browsers. Developing for browsers is a bad idea. Ask IE6.
Exactly! That’s an excellent argument for using PE and writing device-agnostic code!
Taking partial quotes and out of context to boot doesn’t make you cute 
You said it was an intranet? You’d know every user and what devices/browsers they’re using. That’s not the case for public services even if they’re behind a login.
I did, as an example. And I definitely know that all intranets are not that closed - so that you’d know every user and device. And you didn’t answer the question - I’m asking what you consider part of the web, and what you consider to be needing to follow your principles?
Great! Let’s use pointer events: it has good cross-browser support. Except for Safari. But who cares - that’s only used by 5% of the desktop market and Apple should “keep with the times”!
The point is that PE allows you to use modern technologies without waiting for others to catch up. Why is that a problem?
It’s not a problem at all, in some cases! Maybe even most cases, I don’t know; but in every case I believe that the developers/owners have the right, and the freedom, to do whatever is correct for their application. It doesn’t really matter what you think, or their users think, even - if their users dislike the service, then they’ll go elsewhere 
I personally might steer away from things that 5% of the market can’t use; Jane Doe developer down the road might disagree, and think that that 5% wasn’t relevant to her app. Who am I to judge her for that decision? She knows her clients, app, and stats better than I do!
If you develop for a subset of browsers, only people with those browsers will use your site. Those who can’t use it will disappear from your audience and statistics. They rarely complain - they just go elsewhere.
And if that’s not a problem for you, then fine! If it is… then do something about it. I don’t see why this is a contentious point.
PE allows you to develop for the web - not browsers. Developing for browsers is a bad idea. Ask IE6.
IE6? Is that an argument of some kind?
https://www.modern.ie/en-us/ie6countdown
PE is a fine idea sometimes, especially when dealing with static, informational content; and maybe some of its ideals can be employed in more complex applications, but as a standard across all of them? It just doesn’t make the same sense to me as it does to you.
When it’s not content based or requires user input/interaction.
You could tear that statement if you wanted to, but it’s a pretty clear distinction if you’re not being pedantic. Facebook, Soundcloud, Discourse, Netflix, Reddit, etc. are all apps. They are all heavily reliant on user input, user interaction, and usability. Wired, Sitepoint (the site), Medium, MSDN, or your local Mexican Restaurant site are not apps. They are sites.
Basically if it’s not an article/blog, a reference, or a business’s “web presence”… it’s probably an “app”. However, all could probably be enhanced by JavaScript, I’d say working without it is just as important. Now… the CMS that’s probably used to fill the content of those sites is definitely an app.
Of course you have the right to develop web applications however you like (legal obligations permitting). Use table layouts. Use spacer GIFs. Use ActiveX. Use JS-only sites.
But I don’t see why that’s an argument against PE?
You think it’s not? The reason IE6 hung around so long was not the (total) fault of Microsoft or systems administrators. It was because developers wrote code which worked in one browser. While the situation isn’t quite so bad now, it’s happening again: developers are targeting three or four modern browsers. We never learn.
It’s not quite so clear-cut. Does adding a search and contact form make your web site into an app? More specifically, does adding a few forms become a justification for using a JS framework?
I’m not saying you should never use Angular/whatever. But to shun PE as a technique or suggesting it’s a bad practice (#46) in all situations is nonsense.
I think that it’s because PE smells like it’s hard work, where you have to personally do all of the development.
Is it possible for any given framework to supply PE as a natural part of their support? In many cases it can be, for example, this Javascript Micro Frameworks and Progressive Enhancement article uses Backbone to create the TODO app and shows how PE can be maintained throughout the process.
It does take extra work, but that is the cost of anything that’s well crafted.
It can also be argued that when you support the 1%-2% of visitors that don’t support JavaScript, that they will keep on coming back to you time and time again purely because you are one of the few that they can access.
4 Likes
But I don’t see why that’s an argument against PE?
It’s not, at all. It’s simply an argument against the attitude that PE globally fits all ideas and projects’ requirements and that your view is superior to all others
And of course, not using PE is not at all similar to tabling and spacers, but once again, we have to try to be unnecessarily derogatory and irrelevant to make points apparently.
You think it’s not? The reason IE6 hung around so long was not the (total) fault of Microsoft or systems administrators. It was because developers wrote code which worked in one browser. While the situation isn’t quite so bad now, it’s happening again: developers are targeting three or four modern browsers. We never learn.
I guess we have to agree to disagree about this - I don’t think that’s the case at all. I instead feel that if developers wrote code that only worked in IE6, that the businesses shouldn’t have been mired into that scenario in the first place, especially as it became outdated. The difference here is that they’re modern browsers. Will things become outdated some day? Sure. For currently in-use apps, presumably they’re being maintained and updated. For simple informational sites? Maybe (hopefully?) they have some of your PE techniques, or are less reliant on technology that may change. If not? They’ll have to be remade in the future, or modified. That’s the way of the Internet.
I’m not saying you should never use Angular/whatever. But to shun PE as a technique or suggesting it’s a bad practice (#46) in all situations is nonsense.
That’s what you’re implying though, in reverse - that not using PE in all situations is a bad practice. My position is that PE, along with any other programming technique, has a use case. A pretty broad one, in fact, in this case - but it doesn’t apply to everyone/every project, and those that don’t use it aren’t inferior by default because of it, although they certainly can be for other reasons.
1 Like
I don’t think anyone’s suggested that? I think we agree that you should use the right tools for the job but, unfortunately, there’s a tendency toward using JS frameworks regardless of the project.
I disagree. First, this is the web - not the Internet - and many argue URLs should never change.
While technology moves on, PE allows you to future-proof your code. Of course, things are never that easy but PE concepts have proved themselves over a long period.
I wasn’t but…
-
If you use PE, your application shouldn’t fail on any device or any browser today or tomorrow. You’re building fault-tolerance.
-
If you use a JS-framework, your application will fail for some users and search engines today. Tomorrow is an unknown quantity but relying on JS inevitably makes it more fragile.
But you explain that to clients, right?
I still consider PE a development approach. It’s about not relying on specific technologies in specific browsers at a specific point in time. Anyone who’s tried PE knows it’s not significant extra work and the long-term benefits can be considerable (bigger audience, SEO, future-proofing, easier maintenance, etc).
If you’re using a JS-framework you get a lot of goodies out of the box so the initial development can be more rapid. But PE isn’t available and adding it later is virtually impossible without a total rewrite.
I don’t think anyone’s suggested that?
That’s definitely the attitude you’re conveying, but fair enough.
and many argue URLs should never change.
When did we discuss altering URLs?
PE allows you to future-proof your code
Again, fair enough, but in modern and future use cases, I sincerely doubt that the norm would be to employ outdated or archaic code that has reverted to only being able to display basic HTML content due to compatibility issues. Successful PE? Sure. Actually something people would use in this hypothetical future? Not if there are any other options.
If you use a JS-framework, your application will fail for some users and search engines today. Tomorrow is an unknown quantity but relying on JS inevitably makes it more fragile.
But you explain that to clients, right?
The client’s opinion is all that matters, to some degree. Or employer, whichever. If they believe that their market is strongly modern browsers, and they believe that the added value of the framework/etc or the time saved are worth the potential loss of non-JS or other users… then that’s their call. I’ll advise them on my experience/opinion/statistics/whatever is required… and they’ll make a call.
At the end of the day, that’s that.
I’m all for PE as an approach when the job calls for it. My point, one which won’t be altered by this discussion, is simply that your one approach cannot be, and is not, the overall best for all projects, when considering the application requirements, time and money constraints, user base, usage statistics, etc. I’m content to leave it at that, but if you have further points to make to me in specific, feel free, as I’m sure you will
1 Like
It is a product of logical progression…
While not necessary the users getting a rich experience is what continues to drive Internet evolution forward.
Just as when using a Win PC or Mac a tablet or smart phone the event driven GUI interface is one of the biggest innovators that launched forward progress and arguably productivity. Was it needed? I used PC’s before Windows. Some still love the Linux/Unix command line. But not the average person.
Logically the rich user experience should be core to HTML / CSS / RICH UI ACRONYM HERE
I suspect long before that happens given the non-speedy rollouts of W3C we will see things go a very different way.
As usual, its the game developers that push the edge. In scant time in this technology it results in innovation and standards in time. The interactive natures of multiplayer console games (all obviously developed on PC’s) are what are going (are) driving Internet technology to come. This is sorta right around the corner. Its one of the main reasons we are looking at Windows and Mac online OS’s and smart clients. Like going back 35+ years to servers and smart terminals.
Browsers will outgrow Javascript and HTML, the “smart client software”. Instead, they will as games do have smart objects built in and an object based data structuresl doing data transport. This brings forth smart device unification, computer, game system, phone, tv, watch, goggles, tablets and who knows what else. Point being, “mobile first” will be “mobility first” and its all event driven. While escript might still lay as a basis Javascript will wane. Its simply not up to the task of complex data structure transport efficiently. Mobile games use it now, but for a really complex game where there is a enormous variety of datum moving to and fro, wont do.
As we transition into this new Internet be lots of fallout and lots of startups. Design firms, small freelance development firms are dead. The big players, Adobe, MS, etc. are already moving and WAY ahead of the freelances/small operations community. .NET/Mono will be at least the initial punch as its the only game in town really. Widely used, professional dev environment, scalable, enterprise ready, happily will jibe with any popular OS and database software from mySQL to SQL server to Oracle etc. C# is now near as fast as Java and its footprints gotten alot smaller, multi-threaded etc etc. PHP is as good as dead already. Microsoft has done quite a bit with managed C++ as well to support existing enterprise codebases in the coming transition.
Whats important to realize is where your skill sets are .vs. what is coming. If one waits to learn C#, .NET etc then one is behind the curve of opportunity coming. As when it comes there will be plenty to learn in as far as how all these new constructs and data structures deal with smart clients.
On the other side of this entire deal is reason. That being also capability to regulate.
1 Like
Initially the grand website was built.
Then it was found that several sections of the market had trouble, and so a top-down approach of graceful degradation was born.
Graceful degredation was found to be a lot of hard work. Easier to achieve was a bottom-up approach from the start, of progressive enhancement.
Finally people stopped caring as much and returned back to the grand website approach once again.
Where do I get off this treadmill!
Pick the spot that best suits you and step off.
2 Likes
Apologies, but I never stated you shouldn’t use JS frameworks. I only said there’s a tendancy to use them regardless of the project. There are some strong use-cases: games, intranets, sophisticated interfaces etc. But there are some weak ones: content, basic form-driven apps, etc. I think we have agreed on that point.
You stated that apps would eventually change or die. But, budget and usefulness permitting, apps (and therefore URLs) need never die. I’m using some ancient apps which haven’t changed in more than a decade but they remain useful (thanks watchthatpage.com!) They could be upgraded but there’s little commercial or practical benefit.
You appear to have a limited view of PE. It’s not about showing basic HTML or supporting ancient browsers (although that is possible). It’s about enhancing a baseline experience when browsers offer specific features. CSS does that by default - the browser ignores properties it doesn’t understand. With JS, you test for support before adding functionality. For example, you might show a standard “file browse” upload control which works (almost) everywhere but, if the browser supports drag and drop, that functionality is introduced.
An identical app could be developed using a JS framework or PE. The only difference is the approach.
Agreed. But clients are the first to shout when their site doesn’t appear at the top of Google for a word or phrase because it’s been generated by JS.
I think it’s time to step off and cover these points in a SitePoint article!
1 Like
I only said there’s a tendancy to use them regardless of the project.
I didn’t say that you stated anything, I said that was the attitude you’re conveying. An example quote:
Of course you have the right to develop web applications however you like (legal obligations permitting). Use table layouts. Use spacer GIFs. Use ActiveX. Use JS-only sites.
That implies that my argument against universally using PE is similar to arguing to build layouts with spacer GIFs or ActiveX, which implies that you think that if a developer doesn’t use PE exclusively except for a rare instance, then they’re absurd. If that’s not what you were meaning, than alrighty
I’m happy to agree that PE is an approach worth having sometimes, and that JS frameworks (or whatever other newer ideas, approaches, techniques, etc) are also worth having sometimes, if you are
You stated that apps would eventually change or die. But, budget and usefulness permitting, apps (and therefore URLs) need never die.
OK, so just a misunderstanding there, I thought you were somehow saying that not using PE results in having to change URLs, which made no sense - I can’t see how any development approach of any kind requires that
I guess though that I’m including budget and usefulness in my thought that most apps will change or die. You can’t say that most 90’s or even early 00’s websites and/or applications are still existing and used by a large market in their exact original form? I definitely know of some examples, but that’s certainly not most of them. That’s because in most cases there is a commercial (or practical) benefit to change - consumers expect certain things and in order to drive stats/sales/whatever your project does you’ll have to fit their expectations.
You appear to have a limited view of PE.
I think that I understand PE just fine, but my issue is with the baseline - I feel like a lot of applications have a baseline of interaction or appearance that, below which, users will not engage and or the app won’t be useful at all. PE mindset would argue that I spend time ensuring that my application shows as much content as possible to people far below that baseline, and consider them and their needs, when common sense and statistics tell me that that fractional market for the specific app in question is not worth that time or money. You’ve stated that it’s sometimes not commercially viable to upgrade an application or it’s UI. Fair enough. I’d just imagine that there are often times when it’s also not viable to support archaic technologies for no return on that investment. Even with a proper PE approach, there’s still time invested both at the start, and later on in the project.
Agreed. But clients are the first to shout when their site doesn’t appear at the top of Google for a word or phrase because it’s been generated by JS.
The clients are the first to shout about anything. I can’t imagine you’ll find many people here who will argue with that
Sidebar on JavaScript and SEO:
Just to be clear to anyone who is reading who isn’t - JavaScript does not mean Google can’t crawl your content. They still recommend that crucial content be available without it, but Google does execute some JavaScript. There are also a bunch of considerations when setting up your hosting/filesystem/etc. to help that. Anyway - @ceeb is definitely correct that sometimes JavaScript content can be bad for SEO - and that’s another point in favor of SE or some sort of degradation for static content based websites. But the idea that Google can’t deal with JS is definitely not always the truth anymore, and undoubtedly will be less so in the future.
I didn’t bother reading all 97 responses before mine. Anyway, my opinion:
If your site is based primarily on viewing content, RENDER WITHOUT JS. If your site is mostly interactive in such a way that removing the interactivity makes the site practically useless anyway, RENDER WITH JS (assuming it simplifies your development). BUT, in any case, I don’t see why someone can’t just throw a few lines of HTML (in a <noscript> tag) onto the base page saying something along the lines of “This site requires JavaScript enabled to function properly. Please enable JS before using this site”. And also throw SOMETHING in the HTML to indicate to users that the app is loading so they aren’t staring at a blank screen while they wait for the app to initialize.
Note: I understand that many interactions can be handled as forms and then enhanced with JS, but then you are often building the same functionality twice: once on the back end and once on the front end. As an industry, we are moving toward using the back end as a service for handling data rather than an app server that handles everything.
1 Like
It is far easier to forget the noscript tag and simply code it directly in the HTML. It can then be easily removed using JavaScript if the appropriate JavaScript commands are supported (thus allowing for browsers that support JavaScript but which don’t support all the commands you need).
The noscript tag is as obsolete as Netscape 4 (the last browser that needed it)
The noscript tag has semantic meaning to someone reading the HTML code. Many people were mentioning people disabling JS and this tag works perfectly fine for that without needing to add more JS to remove it. I don’t see why you would switch from the noscript to a different tag that requires you to add CSS and JS to get it to act like a noscript tag when the noscript tag has that all built in?