5 ms·

That sounds nice on paper. But would it not be a security nightmare and result in browser fragmentation? I rather tell my customers to embrace HTML and a conce

That sounds nice on paper. But would it not be a security nightmare and result in browser fragmentation? I rather tell my customers to embrace HTML and a concept where a URI has a main concern and if I want to see that concern, I have to load the page. I like to build web applications that work without Javascript, but enhance the page for better user experience, when activated. (Like the old (sane) times.) It would be so nice, if I can just mail a link or make a bookmark and when I follow that link, I don't get a firework from a client-side application that tries to magically restore state. BTW. I have JS deactivated by default and I am not the only one (security measures, privacy, insane amounts of JS loaded by e.g. news pages). I tend to be annoyed, if the page does not work without JS.

smeyer 12y ago
You're obviously not the only one who deactivates javascript by default, but a quick google brought up numbers of around 1% for users with javascript deactivated. I can see why a lot of developers wouldn't be too concerned about that 1%.
- dietrichepp 12y ago
  The 1% includes a lot of crawlers, although not Google's.
- einrealist 12y ago
  That is sad in a way. I expected the number to be much higher. I am interested in to know why the majority does not use Javascript blockers. Here is a source for the 1%: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
- vanadium 12y ago
  It used to be that a significant portion of that 1% (and those that also turned off CSS) were from those leveraging screenreaders some years back; with the uptake of ARIA and better screenreaders, not so much the case anymore. So there was once a definite use case for supporting them in a B2C context, at least. You still see it in .edu/.gov/.mil quite a bit as a requirement (Sec 508, et al).
- idlewan 12y ago
  There's a lot more people than 1% that sometimes have javascript disabled: EVERYONE has javascript disabled until the js payload is downloaded. Which is extremely important on high-latency or slow network connections.
susan_hall 12y ago
>browser fragmentation The possibility of browser fragmentation ceases to exist in a world of polyglot browsers. You would instead have fragmentation in the sense of many languages running on the runtime, and there the individual languages would presumably have their own system of managing dependencies, just like on the JVM now. > a security nightmare Sandboxing becomes an issue of the runtime. Assuming there is a standard runtime, then security could be managed as it is now. > where a URI has a main concern Those days started to end in 2004, with Ajax, and those days have suffered further retreat with WebSockets, and will likely cease to exist as people combine more data in one place. Have you seen how many Ajax calls your typical Angular app makes to construct one page? The original concept of the URI is undermined -- instead of a scalar value, most pages are now a vector of URIs. >I tend to be annoyed, if the page does not work without JS. My comments are only directed to those who are trying to offer software as a service. Those are services where the Javascript must be on. My remarks have no relevance for those traditional pages that you can view without JS. However, clearly, the industry is investing a great deal in sites that work as pure software -- it is for those sites that the old ideal of HTTP/HTML as a publishing platform is a handicap rather than a benefit.
- einrealist 12y ago
  As I said, your polyglot browser idea looks nice on paper. Look at the current state of browser development and how hard it is to push standards like HTML5 or Ecmascript 6 and take a look at the differences on how and when browser vendors implement those standards. And what languages should be supported? Who provides the runtime environments? What about the different devices and their capabilities? Sandboxing is hard, very hard. You would be afraid to even open a browser window if you know enough. If you like to have a strong sandbox, you cannot use plugins. You cannot even use fonts or render images - not to speak of video. Using fancy HTML5 APIs like to access file system or device sensors? Gone. WebGL, well... Ajax made URIs more important than ever. Everyone started to speak about APIs (first Widgets) and a dissertation of a guy named Fielding became really important, because people had to (re)learn the basics of the web (and are still learning). WebSockets are for data streams and you cannot compare that to your typical browsing session. For me, Single Page Applications are nice for Dashboards or simply pages which federate data and are open for longer sessions. I do not condemn them. What I don't like are Single Page Applications which exist for the sake of a Fatclient-like experience. It creates so much more complexity when I have to work around the limitations of HTML. Angular, Ember or ExtJS are complex and it becomes a huge dependency/constraint. You have to duplicate so much business logic, because you cannot trust the client. You have to validate everything server-side. That's why there are approaches like Dart, GWT/Vaadin or even NodeJS. I like it the other way around - old school. Javascript to enhance, not to enforce. Take Gmail: I like to bookmark important mails. When I open that bookmark, I like to see the message. But Gmail has to boot first. And this is really optimized compared to your usual Angular application. Why can't I just see my mail - rendered with plain HTML + CSS. And when I click one (mock) button (e.g. reply), the page becomes enhanced immediately (because it loaded the necessary script in the background). We could even be better at UIs, which do not try to put as much information on the screen as possible. Another good example is Atlassian. I really like their applications. Nearly everything can be opened in a new tab. On each page, I get the main information (the concern) first and when I need more, I can get that - even with heavy Javascript support. Everything that's important uses Javascript unobstrusively. I like that. I can link/bookmark that. If you want people or entire businesses to share links and information effectively, Single Page Apps are not the answer.

smeyer 12y ago

You're obviously not the only one who deactivates javascript by default, but a quick google brought up numbers of around 1% for users with javascript deactivated. I can see why a lot of developers wouldn't be too concerned about that 1%.

dietrichepp 12y ago
The 1% includes a lot of crawlers, although not Google's.
einrealist 12y ago
That is sad in a way. I expected the number to be much higher. I am interested in to know why the majority does not use Javascript blockers. Here is a source for the 1%: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
vanadium 12y ago
It used to be that a significant portion of that 1% (and those that also turned off CSS) were from those leveraging screenreaders some years back; with the uptake of ARIA and better screenreaders, not so much the case anymore. So there was once a definite use case for supporting them in a B2C context, at least. You still see it in .edu/.gov/.mil quite a bit as a requirement (Sec 508, et al).
idlewan 12y ago
There's a lot more people than 1% that sometimes have javascript disabled: EVERYONE has javascript disabled until the js payload is downloaded. Which is extremely important on high-latency or slow network connections.

susan_hall 12y ago

>browser fragmentation The possibility of browser fragmentation ceases to exist in a world of polyglot browsers. You would instead have fragmentation in the sense of many languages running on the runtime, and there the individual languages would presumably have their own system of managing dependencies, just like on the JVM now. > a security nightmare Sandboxing becomes an issue of the runtime. Assuming there is a standard runtime, then security could be managed as it is now. > where a URI has a main concern Those days started to end in 2004, with Ajax, and those days have suffered further retreat with WebSockets, and will likely cease to exist as people combine more data in one place. Have you seen how many Ajax calls your typical Angular app makes to construct one page? The original concept of the URI is undermined -- instead of a scalar value, most pages are now a vector of URIs. >I tend to be annoyed, if the page does not work without JS. My comments are only directed to those who are trying to offer software as a service. Those are services where the Javascript must be on. My remarks have no relevance for those traditional pages that you can view without JS. However, clearly, the industry is investing a great deal in sites that work as pure software -- it is for those sites that the old ideal of HTTP/HTML as a publishing platform is a handicap rather than a benefit.

einrealist 12y ago
As I said, your polyglot browser idea looks nice on paper. Look at the current state of browser development and how hard it is to push standards like HTML5 or Ecmascript 6 and take a look at the differences on how and when browser vendors implement those standards. And what languages should be supported? Who provides the runtime environments? What about the different devices and their capabilities? Sandboxing is hard, very hard. You would be afraid to even open a browser window if you know enough. If you like to have a strong sandbox, you cannot use plugins. You cannot even use fonts or render images - not to speak of video. Using fancy HTML5 APIs like to access file system or device sensors? Gone. WebGL, well... Ajax made URIs more important than ever. Everyone started to speak about APIs (first Widgets) and a dissertation of a guy named Fielding became really important, because people had to (re)learn the basics of the web (and are still learning). WebSockets are for data streams and you cannot compare that to your typical browsing session. For me, Single Page Applications are nice for Dashboards or simply pages which federate data and are open for longer sessions. I do not condemn them. What I don't like are Single Page Applications which exist for the sake of a Fatclient-like experience. It creates so much more complexity when I have to work around the limitations of HTML. Angular, Ember or ExtJS are complex and it becomes a huge dependency/constraint. You have to duplicate so much business logic, because you cannot trust the client. You have to validate everything server-side. That's why there are approaches like Dart, GWT/Vaadin or even NodeJS. I like it the other way around - old school. Javascript to enhance, not to enforce. Take Gmail: I like to bookmark important mails. When I open that bookmark, I like to see the message. But Gmail has to boot first. And this is really optimized compared to your usual Angular application. Why can't I just see my mail - rendered with plain HTML + CSS. And when I click one (mock) button (e.g. reply), the page becomes enhanced immediately (because it loaded the necessary script in the background). We could even be better at UIs, which do not try to put as much information on the screen as possible. Another good example is Atlassian. I really like their applications. Nearly everything can be opened in a new tab. On each page, I get the main information (the concern) first and when I need more, I can get that - even with heavy Javascript support. Everything that's important uses Javascript unobstrusively. I like that. I can link/bookmark that. If you want people or entire businesses to share links and information effectively, Single Page Apps are not the answer.