The web, it's for everyone(thewebitsforeveryone.tumblr.com)
thewebitsforeveryone.tumblr.com
The web, it's for everyone
http://thewebitsforeveryone.tumblr.com/
75 comments
I agree with the principle of this, but i disagree with including the javascript-is-disabled errors. If you browse the internet with one of the most important components of the internet disabled, you're going to find that a lot of stuff is broken, and displaying a warning that "hey, things are going to be broken here" is preferable to just displaying broken stuff.
You might be surprised at what can be accomplished with HTML and CSS alone. Most of github.com works just fine without Javascript. Much of Twitter and Facebook work too. Facebook does give a warning, but they say you should enable Javascript "for a better experience" instead of "for any experience."
I agree that showing a "hey this is broken" warning is better than rendering a totally broken page, but it's still not as good as presenting at least a partially working version, perhaps minus all of the usual bells and whistles. Now, of course, this is not super-feasible if you've chosen to build most of your site using client-side code, especially if that's where most of the rendering happens. But then again, the lack of server-side rendering is the obvious downside of building your site that way.
I agree that showing a "hey this is broken" warning is better than rendering a totally broken page, but it's still not as good as presenting at least a partially working version, perhaps minus all of the usual bells and whistles. Now, of course, this is not super-feasible if you've chosen to build most of your site using client-side code, especially if that's where most of the rendering happens. But then again, the lack of server-side rendering is the obvious downside of building your site that way.
Not everyone has the resources that Twitter and Facebook have to mantain what essentially are two version of their website.
My position is that if you disable Javascript you get what you get (both you and I will be happy to know that I don't do web development anymore).
My position is that if you disable Javascript you get what you get (both you and I will be happy to know that I don't do web development anymore).
If you use progressive enhancement, you don't really need two versions. You have the base version, and you layer javascript and css on top of it. Granted, it might be a bit more work than just rushing out a javascript-dependent version, but it's definitely not twice the work. And you then have a much better structured, more solid base to work on - in the long-run, I'd be surprised if it weren't less work to do things the progressive way.
I find that "progressive enhancement", while perhaps a bit more work, results in a more robust and maintainable webapp. The fact that results in pages that work without JS is almost a side-effect and barely needs to be tested.
The point for me is that links behave like links (perform GET requests against a URL and change the page from one state to another), buttons behave like buttons (perform POST requests and update some internal state), and the effect they have on the page is much the same with or without Javascript. The only difference is that with Javascript I can intercept the action and make the state change a lot more streamlined, or add a fancy animation if I so desire.
By simply intercepting buttons and links (similar to how pjax and turbolinks work) I don't have to dig through JS to find where a specific AJAX request is fired-off and what it does. It just works, and when it returns, it simply updates part or all of the page with whatever the server returned, which could be part or all of a page.
There are, of course, obvious limitations, like local state that changes with user interaction but that isn't preserved on the server in any way. But the more I can get working without Javascript, the more I know will be easily maintainable and translatable going forward even if I do something crazy like get rid of jQuery or convert everything to a React app.
Maybe I'm just a bit odd, but I find this approach a lot easier to manage and a lot more productive in the long run than in marrying myself to any particular client-side framework.
The point for me is that links behave like links (perform GET requests against a URL and change the page from one state to another), buttons behave like buttons (perform POST requests and update some internal state), and the effect they have on the page is much the same with or without Javascript. The only difference is that with Javascript I can intercept the action and make the state change a lot more streamlined, or add a fancy animation if I so desire.
By simply intercepting buttons and links (similar to how pjax and turbolinks work) I don't have to dig through JS to find where a specific AJAX request is fired-off and what it does. It just works, and when it returns, it simply updates part or all of the page with whatever the server returned, which could be part or all of a page.
There are, of course, obvious limitations, like local state that changes with user interaction but that isn't preserved on the server in any way. But the more I can get working without Javascript, the more I know will be easily maintainable and translatable going forward even if I do something crazy like get rid of jQuery or convert everything to a React app.
Maybe I'm just a bit odd, but I find this approach a lot easier to manage and a lot more productive in the long run than in marrying myself to any particular client-side framework.
Yes, that's the ideal. Try and do it. Remember to test all the different progressively enhanced paths that only a tiny minority of your users is using.
Do you also take that attitude to your code? I.e. "it's alright, that code path only executes one time out of fifty, doesn't matter that it crashes the program".
That is not what I meant. I meant: “that code path only executes one time out of fifty (thousand), but you have to test it exactly like the core code that runs thousands of times more, so maybe you can drop the feauture since it's used by a handful of users”.
(I have my doubts one in fifty people disable Javascript)
(I have my doubts one in fifty people disable Javascript)
Well now you're talking about an analogy that's 3 orders of magnitude away from what we're actually dealing with, so it doesn't really hold up. BTW, we're not really talking about 'testing' here, either - you don't actually need to test plain HTML beyond the most cursory of glances.
We are talking about people disabling JavaScript in their browser. One in several thousands is still a large over estimation.
[Citation needed]
What a thoughtful and insightful remark. If you don't believe that statement to be in the right ballpark you are out of touch with the world outside HN.
You could always just build one version that is capable of rendering either server-side or client-side. React.js and other similar frameworks (that do diff-based updates) work well with this, or at least better than frameworks where the state changes are discretely coded.
The react-rails gem is capable of doing server-side rendering out of the box: https://github.com/reactjs/react-rails
The react-rails gem is capable of doing server-side rendering out of the box: https://github.com/reactjs/react-rails
In my experience, when discussing development problems, there are two types of people: those that say “well, you could just […]” and those that tried to do it and learned from experience how many unexpected problems you are going to have, how much work it's going to be, how much more testing you need, etc.
Fair. I haven't tried rendering server-side with React. I'm sure it's as much a maintenance nightmare as much as any major feature.
But I do have apps I maintain that started as traditional Rails apps and have been progressively enhanced to a point where they perform a lot like more modern client-side apps. And an interesting property I've discovered to be true of such an app is that it's really quite easy to convert that traditional view-rendering pipeline to React, because there is almost no JS-soup being relied on for core pieces to function.
On the flip side, I also work on a couple apps where most of the functionality exists as JQuery DOM manipulation or as Bootstrapified data binding, and these are nearly impossible to port to a diff-based rendering library like React without rewriting most of the functionality.
So while I haven't exactly tried rendering React on the server, I've found that the more traditional server-side rendering flow still holds up quite well on the modern web. It's a good way of thinking about how your app should look/behave given a set of states, and it holds up well even in places where Javascript is required. The fact that it can be accomplished without Javascript is more of a side-effect, but also a good indication that it's not any particular bit of Javascript that is holding it all together.
But I do have apps I maintain that started as traditional Rails apps and have been progressively enhanced to a point where they perform a lot like more modern client-side apps. And an interesting property I've discovered to be true of such an app is that it's really quite easy to convert that traditional view-rendering pipeline to React, because there is almost no JS-soup being relied on for core pieces to function.
On the flip side, I also work on a couple apps where most of the functionality exists as JQuery DOM manipulation or as Bootstrapified data binding, and these are nearly impossible to port to a diff-based rendering library like React without rewriting most of the functionality.
So while I haven't exactly tried rendering React on the server, I've found that the more traditional server-side rendering flow still holds up quite well on the modern web. It's a good way of thinking about how your app should look/behave given a set of states, and it holds up well even in places where Javascript is required. The fact that it can be accomplished without Javascript is more of a side-effect, but also a good indication that it's not any particular bit of Javascript that is holding it all together.
For eight-ish years, 2002-2010, I made websites that worked with or without Javascript, precisely because I didn't want to make two websites. I would have had to, because a lot of blind people used to use readers that didn't always handle Javascript well, and the sites I made were required to be accessible.
Admittedly, they did not look as good as sites do today.
Admittedly, they did not look as good as sites do today.
I think one problem is that it's actually a lot more expensive to build an interactive application-style site that works with well with javascript disabled. So sure, rich companies like Github, Twitter, and Facebook can (and I think should) invest in making things work relatively well. But a less rich company is faced with a choice between giving up that interactivity or committing to it. Most people have gotten used to the interaction patterns of javascript-heavy sites, so giving it up can put a company at a UX disadvantage, with no real pay-off, because it is very uncommon for people to turn off javascript. On the further end of the scale are applications like Google's inbox, which are largely designed around interactivity of the sort you need javascript to achieve, and are never going to work any other way (though it's very silly that it requires Chrome).
Whatever happened to "progressive enhancement"? It's possible to build a very rich experience around standard HTML+CSS and then enhance it with Javascript. This is how much of Github works. I'm not saying you should always take that approach, but if you're a small company with limited resources you can still choose which route you want to go down, and if you choose "progressive enhancement" then you have a site you know will (mostly) work without JS, without having to do any extra work on top of you usual development process. Rich companies can, of course, take both routes, but if you're going to build a javascript-heavy site you should at least understand the trade-offs and alternatives before you dive in head-first.
I feel like I specifically spoke to this in my comment that you responded to, but I guess I wasn't clear. My whole point was that doing progressive enhancement really well is much more expensive and has very little practical pay off (because within the margin of error, everybody has javascript turned on), so if you know you want lots of interactivity, it is reasonable to require javascript from the start. That is an understanding of the trade-offs.
The part I might be wrong about is "doing progressive enhancement really well is much more expensive" - that's just my opinion based on anecdotal experience.
The part I might be wrong about is "doing progressive enhancement really well is much more expensive" - that's just my opinion based on anecdotal experience.
What happened to progressive enhancement is that it's a fair bit of work, and putting in extra hours to support the three "power users" who have decided they want to run noscript isn't worth my time.
It is only a problem if you disregard all previous experience and knowledge and write your app directly in javascript rather than writing it in html+css and then using javascript to provide enhancements.
Taking my previous experience and knowledge into account, it is easier and cheaper to create richly interactive applications by requiring javascript than by using progressive enhancement. Your experience and knowledge is certainly allowed to be different than mine.
I just tried disabling JavaScript and visiting Facebook and Twitter... both were entirely unusable. Nothing on Facebook worked, and on Twitter, all of the links and interactions were broken.
I guess it depends on what you mean by 'works' -- I was able to view my facebook profile, click on links, visit other profiles, and even view a few entries on my news feed. Same with Twitter -- profile, news feed, a few other pages. Posting is broken, certainly, but to do that on Facebook I could click on "switch to our mobile site".
I understand the necessity of Javascript if you have a web app, but a lot of sites fail to display a page of text or a list of links if Javascript is disabled [1]. In my view, this is poor practice. What seems to be happening is that more and more people are using Javascript frameworks to build web sites (not web apps). This probably makes things easier for the developer. I'm not convinced it always makes for a better experience for users.
[1] Some examples of sites that won't display anything if Javascript is disabled (even though they're most displaying text): http://googlecommerce.blogspot.co.uk/ http://googleandyourbusiness.blogspot.co.uk/
[1] Some examples of sites that won't display anything if Javascript is disabled (even though they're most displaying text): http://googlecommerce.blogspot.co.uk/ http://googleandyourbusiness.blogspot.co.uk/
Could not agree more! We have an mainly internal-only app that I work on that started out as PHP+HTML+CSS only and then over the years JS has been bolted on in various places. At first it was just to make life easier (Autocomplete, minor AJAX) but now we have entire components that will not function without JS and could not function without JS. Recently some devs have pushed for supporting browsers without JS enabled and I have been vehemently against it for a couple reasons:
1) MAJOR parts of our app will not and can not work without JS. Period, exclamation point.
2) Because of point 1 it doesn't make sense to waste dev time on making some views work with/without JS (We are a younger company and don't have time to waste on something like this especially when it isn't public-facing, not to mention QA can't handle testing everything twice).
3) Even if V1 of a component does support both JS and no JS there is no guarantee that future updates will be able to keep feature-parity or have time to code for that.
For me JS is part of the web, not an optional add-on. It would be like saying "make a webpage that works with HTML" (IMHO).
I also feel that it's not fair to complain about the GOOGLE CHROME app store requiring GASP GOOGLE CHROME (Same for GOOGLE cloud print). Not shit sherlock. As for Apple not allowing their video feeds on anything but Safari+OS X I think this is BS, there is no good reason I can think of to alienate so many people on other OS's especially since I would think THOSE are the people you might want to reach with your keynotes to convince them why they should switch.
So while I like the idea of this Tumblr I can't help but think the JS/Google Chrome examples don't really fit and distract from the overall message. To be honest looking through the Tumblr again the ONLY valid concern is the one with Apple's keynote streaming, the other ones make complete sense. How is it Google's fault that they are pushing the envelope in terms of what is possible, even Google doesn't have the time/resources to make every one of their ideas (which may or may not make it long term) work across the board and that is their prerogative.
1) MAJOR parts of our app will not and can not work without JS. Period, exclamation point.
2) Because of point 1 it doesn't make sense to waste dev time on making some views work with/without JS (We are a younger company and don't have time to waste on something like this especially when it isn't public-facing, not to mention QA can't handle testing everything twice).
3) Even if V1 of a component does support both JS and no JS there is no guarantee that future updates will be able to keep feature-parity or have time to code for that.
For me JS is part of the web, not an optional add-on. It would be like saying "make a webpage that works with HTML" (IMHO).
I also feel that it's not fair to complain about the GOOGLE CHROME app store requiring GASP GOOGLE CHROME (Same for GOOGLE cloud print). Not shit sherlock. As for Apple not allowing their video feeds on anything but Safari+OS X I think this is BS, there is no good reason I can think of to alienate so many people on other OS's especially since I would think THOSE are the people you might want to reach with your keynotes to convince them why they should switch.
So while I like the idea of this Tumblr I can't help but think the JS/Google Chrome examples don't really fit and distract from the overall message. To be honest looking through the Tumblr again the ONLY valid concern is the one with Apple's keynote streaming, the other ones make complete sense. How is it Google's fault that they are pushing the envelope in terms of what is possible, even Google doesn't have the time/resources to make every one of their ideas (which may or may not make it long term) work across the board and that is their prerogative.
"I also feel that it's not fair to complain about the GOOGLE CHROME app store requiring GASP GOOGLE CHROME"
I read that as complaining about a WEB APP store requiring google chrome. Web apps tied to a specific browser are destructive to the overall ecosystem; you might as well just distribute native apps.
I read that as complaining about a WEB APP store requiring google chrome. Web apps tied to a specific browser are destructive to the overall ecosystem; you might as well just distribute native apps.
Ok, if Gmail was an app in the Google Chrome store only then that might be a problem but this is "Offline" Gmail which I'm sure is using Chrome-specific API's to do it's magic. Google used to have thing called Google Gears (or something like that) that was a framework that would allow for things like Offline Gmail in FF but if I had to guess they either didn't have great adoption or where too limited in what they could so they dropped it and rolled it's features into Chrome.
What I'm not a fan of is "Lowest-denominator web is the best web" arguement. It's not and I'm sorry but unlimited backwords-compatibility is a pipedream, at some point you have to move forward.
What I'm not a fan of is "Lowest-denominator web is the best web" arguement. It's not and I'm sorry but unlimited backwords-compatibility is a pipedream, at some point you have to move forward.
There are non-Chrome-specific "offline" APIs. Some already found in the wild, and some still exist as specs. Google is free to roll their own and keep it to themselves, but I think it's perfectly okay to shame them when they do. It's the same reason I was against ActiveX components in IE. Theres nothing fundamentally wrong with a company pushing things that align with their interests, but there's also nothing wrong with complaining about it like this Tumblr blog does.
Can you provide any details about the internal app? What features does it have that need javascript? Also, since it's internal only, does it even need any extra compatibility, since all the configurations are known? The "web" and the "intranet" are quite different situations.
So while it is heavily used inside our company (where everyone is on the latest chrome) it is also used by LEA's which we do not control. This means we have to support Chrome/FF/Safari/IE 9+ but we have yet to come across a group that disabled JS.
As for what requires JS: we use google maps and people need to be able to draw zones on the maps which is not possible without JS (unless we have them a bunch of text inputs that they could enter the lat/lon of all the vertices. That is just one example and I can't go into much more detail. Bottom line is we would not have the customers we do if we didn't use to make it faster/easier and we don't have to resources to support JS+Noscript/no JS.
As for what requires JS: we use google maps and people need to be able to draw zones on the maps which is not possible without JS (unless we have them a bunch of text inputs that they could enter the lat/lon of all the vertices. That is just one example and I can't go into much more detail. Bottom line is we would not have the customers we do if we didn't use to make it faster/easier and we don't have to resources to support JS+Noscript/no JS.
Javascript is not an important component if the internet. You can argue it is an important component of the web, but even that is pretty sketchy. I do browse without javascript. And 90%+ of the sites I have to turn it on for are just text. Javascript being required for webapps makes sense. Javascript being required for every blog on the planet does not.
While I agree that a user with JavaScript disabled should not expect all fancy features to work, the site should still be able to present its main content in a non-broken visual environment. A minimal version built only with HTML and CSS, which is then expanded upon with JavaScript.
This does appear to be the case with the first warning published on the blog, where the site is put into a "read-only mode" and I disagree with it being listed there, but I come across many other sites which do not display any form of content at all when JavaScript is disabled.
This does appear to be the case with the first warning published on the blog, where the site is put into a "read-only mode" and I disagree with it being listed there, but I come across many other sites which do not display any form of content at all when JavaScript is disabled.
It used to be the case (I haven't checked lately) that certain documentation pages on Apple's site were javascript-only - they were actually blank unless you had javascript on. These were literally just standard text-heavy pages with no discernible client-side behaviour that I ever saw. Whatever side of the argument anyone reading this is on, surely you have to agree that such behaviour is strange in the very least.
The Chrome extension example is pretty weak. I don't know why anyone would think you could get something form the Chrome Web Store using Firefox.
The point is not being open, the point is platform lockin. Once you accept it, you will "never" be able to leave chrome because you have all of your things in chrome apps now.
It was a huge effort to leave the Microsoft lockin back then, and the Web(togheter with Linux, GNU and open source), a open platform did it! It was like the 'man in the moon' back then; And now we are simply going back, and we are just repeating the same mistakes again
It was a huge effort to leave the Microsoft lockin back then, and the Web(togheter with Linux, GNU and open source), a open platform did it! It was like the 'man in the moon' back then; And now we are simply going back, and we are just repeating the same mistakes again
Thank you for pointing this out - I hadn't thought of it that way.
I disagree. Two points:
1. The vast majority of things on the Chrome Web Store are web apps, not browser extensions.
2. Should GMail really only be able to work offline in Chrome?
1. The vast majority of things on the Chrome Web Store are web apps, not browser extensions.
2. Should GMail really only be able to work offline in Chrome?
I understand that many of them are just shortcuts, but the point is still weaker than anything else posted here.
As for your second point, no it shouldn't :( Seems they built this "offline app" stuff into Chrome and plan on keeping it there.
As for your second point, no it shouldn't :( Seems they built this "offline app" stuff into Chrome and plan on keeping it there.
There are specific things you can do in Chrome Apps like access the Hard Drive.
Why can't you at least download it? You can download Firefox .xpi files from https://addons.mozilla.org using Chrome.
They disabled normal local / offline installation of CRX packages a while ago due to "security" concerns.
https://support.google.com/chrome/answer/2811969
https://support.google.com/chrome/answer/2811969
Because “everyone” means people who don’t necessarily follow browser development trends.
I am so torn about this.
On one hand, I think that information should be available to the technological lowest common denominator. I hate apps that should be websites. I hate having my browser use 100% of my CPU for 30 seconds while trying to render a page with just 300 words of actual text content.
On the other hand, I work on web applications and I want to be able to create rich interactions using the best tools available. So I constantly wish I could require all my users to conform to some pretty steep minimum requirements.
I guess it comes down to appropriateness. There is a place for rich applications and there is a place for accessible content.
On one hand, I think that information should be available to the technological lowest common denominator. I hate apps that should be websites. I hate having my browser use 100% of my CPU for 30 seconds while trying to render a page with just 300 words of actual text content.
On the other hand, I work on web applications and I want to be able to create rich interactions using the best tools available. So I constantly wish I could require all my users to conform to some pretty steep minimum requirements.
I guess it comes down to appropriateness. There is a place for rich applications and there is a place for accessible content.
As someone who also enjoys building rich interactions as well, I find that it's just a matter of understanding the trade-offs.
Requiring Javascript support is sort of like relying heavily on the latest HTML or CSS features (a recent example: WebRTC). I have to consider what happens in browsers where the feature is unsupported or disabled, and if I'm okay with narrowing those visitors out of my userbase, then I move forward. Otherwise I make sure that something is in place for them to fall-back on.
Javascript is a bit tricker than, say, the fancier CSS selectors, because I often rely on Javascript for polyfills/webshims, etc, and you can't polyfill a lack of Javascript. But when I can I still make use of that old "progressive enhancement" idea by starting with the basic HTML/CSS elements required to make a feature work, and then enhancing it with Javascript and more modern styling. It doesn't work everywhere, and certainly not in cases where most of the work is done client-side, but I still get plenty of miles out of that technique.
Requiring Javascript support is sort of like relying heavily on the latest HTML or CSS features (a recent example: WebRTC). I have to consider what happens in browsers where the feature is unsupported or disabled, and if I'm okay with narrowing those visitors out of my userbase, then I move forward. Otherwise I make sure that something is in place for them to fall-back on.
Javascript is a bit tricker than, say, the fancier CSS selectors, because I often rely on Javascript for polyfills/webshims, etc, and you can't polyfill a lack of Javascript. But when I can I still make use of that old "progressive enhancement" idea by starting with the basic HTML/CSS elements required to make a feature work, and then enhancing it with Javascript and more modern styling. It doesn't work everywhere, and certainly not in cases where most of the work is done client-side, but I still get plenty of miles out of that technique.
[deleted]
IE and Safari have self-interest motivated reasons for not supporting webrtc and for propagating their own technology, so no, I don't agree with this. I'm not going to avoid building apps that make use of technology that companies like Apple and Microsoft don't implement, and I don't care if that this is a problem for people. These companies don't really want to support the web as a platform. They want a crippled web because it beats their ecosystem lock in.
Not really sure what the point of this is. How do Google Now and GMail Offline == 'The Web'? They are specific Apps designed to work in a specific manner, they are not 'the web'. GMail does work with any browser when accessed via 'the web'.
100% agree with the Apple example though. Why didn't they stream in a more accessible format?! It just served to annoy people and exclude even more people from the Apple elite.
a few years ago banks and financial institutions seemed to be especially bad at restricting access to just IE. Thankfully they seem to have got better, but maybe that's because I don't use Opera anymore!
Originally I thought this was going to be an attack on Hungary's Internet Tax or some freedom of speech protest, alas.
100% agree with the Apple example though. Why didn't they stream in a more accessible format?! It just served to annoy people and exclude even more people from the Apple elite.
a few years ago banks and financial institutions seemed to be especially bad at restricting access to just IE. Thankfully they seem to have got better, but maybe that's because I don't use Opera anymore!
Originally I thought this was going to be an attack on Hungary's Internet Tax or some freedom of speech protest, alas.
> GMail does work with any browser when accessed via 'the web'.
But last I checked Offline Gmail does not. Which I think is the point this Tumblr is trying to make.
But last I checked Offline Gmail does not. Which I think is the point this Tumblr is trying to make.
"Javascript apps don't work when I turn off Javascript :( :( :( :( :( :("
If you think the things made by jerks like me aren't part of the web or whatever, then fine. You stay on your version of the web and I'll stay on mine, and never the twain shall meet.
.....Until you actually need to do something useful.
If you think the things made by jerks like me aren't part of the web or whatever, then fine. You stay on your version of the web and I'll stay on mine, and never the twain shall meet.
.....Until you actually need to do something useful.
Can you provide an example of a useful web-based activity that can't be done without javascript, other than web-based games?
I've seen a huge number of sites over the years stop working because they redesign to incorporate javascript; yet, when I visit them at work (with a javascript-enabled browser) their shiny new site doesn't actually have any new features.
Things that don't need javascript:
--Form verification (you should always be doing this on the server, and optionally in client-side javascript)
--<video> tag
--Popup site menus
--Web-based chat
--Webmail
--Message board comments (unless you locked yourself into Disqus)
--Nearly everything
I've seen a huge number of sites over the years stop working because they redesign to incorporate javascript; yet, when I visit them at work (with a javascript-enabled browser) their shiny new site doesn't actually have any new features.
Things that don't need javascript:
--Form verification (you should always be doing this on the server, and optionally in client-side javascript)
--<video> tag
--Popup site menus
--Web-based chat
--Webmail
--Message board comments (unless you locked yourself into Disqus)
--Nearly everything
AJAX?
Not having to render and reload an entire page every time something changes or a request is made is actually quite useful. Load balancing is one of the reasons js-based templates are so popular.
Also I believe there are aspects of cross-browser compatibility related to mobile design and responsive design which depend on javascript, though I may be mostly wrong.
Not having to render and reload an entire page every time something changes or a request is made is actually quite useful. Load balancing is one of the reasons js-based templates are so popular.
Also I believe there are aspects of cross-browser compatibility related to mobile design and responsive design which depend on javascript, though I may be mostly wrong.
Yes, AJAX does require javascript, but the features provided by AJAX can also be provided by a plain form. You click the "submit" button, the javascript intercepts it, it launches the AJAX server request, and it writes the result onto the page. Without javascript, you click submit, it goes back to the server, and the server returns a page with the result.
Yes, but the usefulness i'm talking about is being able to get a response without re-rendering and fetching the entire page. If the difference between the two is just a small amount of text then doing it asynchronously is faster and more efficient.
Although, if you're just dealing with purely static html pages then I would agree AJAX is pointless. But not everything useful about javascript has to be useful just to the end user.
Although, if you're just dealing with purely static html pages then I would agree AJAX is pointless. But not everything useful about javascript has to be useful just to the end user.
Yeah and the web doesn't need CSS either.... Come on this is ridiculous, web-based chat? Webmail? I can't imagine using those without JS. So the user is supposed to refresh the webpage constantly to see if they got a new chat/email?
>So the user is supposed to refresh the webpage constantly to see if they got a new chat/email?
I remember web chatrooms working that way back when dinosaurs roamed the earth, or maybe they had meta-tags that refreshed the page periodically.
I remember web chatrooms working that way back when dinosaurs roamed the earth, or maybe they had meta-tags that refreshed the page periodically.
http://safe-mail.net/ has a good javascript-free webmail interface. Remember to select the "fast (no scripts or icons)" interface when you sign in.
Why did you need to create a throwaway account for this comment?
I don't maintain a regular account. I mostly lurk, but comment occasionally. When I do, I can't remember my previous username.
Toggle a Menu
The web has moved so far away from its original purpose that we need something to fill the role the web was originally supposed to be for. I hate having to have a massive complex piece of software that takes up a GB of RAM and includes an entire programming language just to be able to view simple text documents that link to each other.
I agree. Browsing is important enough that there should be browsers just for browsing.
What we have now are browsers that support browsing but also support access to web applications. The need to serve two masters makes the browsers we have now suboptimal for just browsing.
In particular, a browser just for browsing would be able to be significantly simpler than a browser that serves two masters, and as a general rule, when we are talking about something as complicated as a browser, making a program simpler makes it more reliable and makes it easier for a human to predict what it will do and consequently makes it less frustrating to use.
What we have now are browsers that support browsing but also support access to web applications. The need to serve two masters makes the browsers we have now suboptimal for just browsing.
In particular, a browser just for browsing would be able to be significantly simpler than a browser that serves two masters, and as a general rule, when we are talking about something as complicated as a browser, making a program simpler makes it more reliable and makes it easier for a human to predict what it will do and consequently makes it less frustrating to use.
Regardless of what the web once was, it now is an application environment, for which one application is documents ("browsing".)
You already have what amounts to a "browser just for browsing" when you turn off javascript in the one you're using now. But a browser which only interprets html and css and not javascript is just a broken browser.
You already have what amounts to a "browser just for browsing" when you turn off javascript in the one you're using now. But a browser which only interprets html and css and not javascript is just a broken browser.
That's the point. The web is completely broken for the use case of "browsing the web". We need a replacement for the web, and for web browsers, to do fill that use case again that the web used to fill.
Your use case, and your definition of "browsing" which excludes dynamic content, isn't typical though. Most people keep javascript turned on by default, and for most people, it isn't broken.
Nothing has changed about HTML or browsers that prevents anyone from building a minimalistic site, or one that degrades gracefully, they just choose not to. This isn't a problem of the web, but the culture of web design, and the tendency of people to only use a few corporate sites which follow the same design paradigms.
Nothing has changed about HTML or browsers that prevents anyone from building a minimalistic site, or one that degrades gracefully, they just choose not to. This isn't a problem of the web, but the culture of web design, and the tendency of people to only use a few corporate sites which follow the same design paradigms.
I didn't say it was typical, what does that have to do with anything. It seems like you are trying very hard to avoid reading my words and instead read what you wish I said.
Yes, it is a problem with the web. The culture of web design is part of the web. This is why we need a replacement for the use case that the web was originally designed for but no longer fills.
Yes, it is a problem with the web. The culture of web design is part of the web. This is why we need a replacement for the use case that the web was originally designed for but no longer fills.
No, I think you're misunderstanding my intent. I'm just saying basic html and hyperlinking still works perfectly fine, and most people read the web as hypertext in almost exactly the same way they always have. The original use case still exists and it still works.
It does not work as well as it used to, and more to the point, it does not work as well as it would if it did not have to do double duty as an application-delivery platform.
On a very long web page, do you ever hold down the mouse button on the slider in the scroll bar so that you can scroll up and down rapidly? If you do that on the web page on which these words appear, it will (probably) work smoothly and well, but on certain Javascript-heavy pages, it is very jerky. The whole page blinks rapidly. It is tedious and difficult to see the text while the page is moving up or down.
That is just one of many examples where a particular functionality useful to people who read and who "browse" (which might be defined as deciding what to read next among many, many alternatives) does not work as well on the web of 2014 as it did in the past because of the need for the web of 2014 to support ever more complicated or sophisticated web applications.
(The many examples include tasks that are not strictly part of reading -- tasks like making a copy of part of a web page or making a copy of the page's URL in preparation for emailing the URL.)
Publishing static documents and reading and browsing static documents over the internet is an important enough function in our society that we should feel sad that it does not work as smoothly and as quickly as it could. The next Einstein and the next Charles Darwin will use the web to learn and to share their discoveries. What the next Einstein and the next Darwin need the most from the web is the ability to browse static web pages quickly and reliably without their having to devote a lot of their attention to the user interface or to getting a particular page to work with their browser.
On a very long web page, do you ever hold down the mouse button on the slider in the scroll bar so that you can scroll up and down rapidly? If you do that on the web page on which these words appear, it will (probably) work smoothly and well, but on certain Javascript-heavy pages, it is very jerky. The whole page blinks rapidly. It is tedious and difficult to see the text while the page is moving up or down.
That is just one of many examples where a particular functionality useful to people who read and who "browse" (which might be defined as deciding what to read next among many, many alternatives) does not work as well on the web of 2014 as it did in the past because of the need for the web of 2014 to support ever more complicated or sophisticated web applications.
(The many examples include tasks that are not strictly part of reading -- tasks like making a copy of part of a web page or making a copy of the page's URL in preparation for emailing the URL.)
Publishing static documents and reading and browsing static documents over the internet is an important enough function in our society that we should feel sad that it does not work as smoothly and as quickly as it could. The next Einstein and the next Charles Darwin will use the web to learn and to share their discoveries. What the next Einstein and the next Darwin need the most from the web is the ability to browse static web pages quickly and reliably without their having to devote a lot of their attention to the user interface or to getting a particular page to work with their browser.
No it doesn't. I have to have a massive complex piece of software that includes and entire programming language and uses a GB of memory to read basic hypertext now. 90% of the sites I need to enable javascript for are just a blog post. Nothing but text and some images, but completely reliant on javascript. A simple browser can not view 99% of the web now. We need a replacement for what the web used to be, because that had value.
The web IS for everyone - even for those who want to make proprietary apps and pages. I don't see a problem with any of these examples unless I missed the one that tax dollars paid for.
You need Chrome to use Chrome extensions? Oh, the humanity!
That said, it's time to call bullshit on Google's whole 'do no evil' shtick, considering how so many of their web apps only work on Chrome.
That said, it's time to call bullshit on Google's whole 'do no evil' shtick, considering how so many of their web apps only work on Chrome.