4 ms·

Yes, but at the cost of: 1. Increased complexity on the server side to handle both cases. 2. Degraded experience on the client side (page reloading for simple

Yes, but at the cost of: 1. Increased complexity on the server side to handle both cases. 2. Degraded experience on the client side (page reloading for simple actions like upvoting).

madez 9y ago
Then let's standardize generic ways that permit things like upvotes without reloading the page and without executing externally supplied code. :-)
- zzzcpan 9y ago
  You can do this already with iframes, link targets and :visited for css classes. Using javascript is unnecessary. This technique used to be popular before XMLHttpRequest.
  - madez 9y ago
    Thanks for providing a solution. If using JavaScript to achieve this is easier/more efficient/better in some other way that is convincing, then we can think about standardizing better ways to do it. And if it's not better using JavaScript, then it's just an issue of raising awareness about not using JavaScript for it.
    - SquareWheel 9y ago
      Embedding hundreds of iframes into existing pages isn't a viable solution. Consider that a single reddit comment requires at least: upvote, downvote, save, report, hide. Not to mention actually commenting, expanding/collapsing threads, or gilding comments. A thread shows 200 comments by default (500 with Gold). Even 200 comments x 5 features requires a thousand iframes, each of which is embedding a complete document. If you think web performance is bad now...
      - madez 9y ago
        > Embedding hundreds of iframes into existing pages isn't a viable solution. I know I'm repeating myself, but then let's standardize a better way to solve the problem without executing supplied code. JavaScript is not a magic bullet that solves problems that aren't solveable otherwise.
        EgoIncarnate 9y ago
        You'll have to come up with proof of a better alternative before you'll get agreement from people like me. Javascript and sandboxed executable code may not be a magic bullet, but it's the bullet we have. "Lets standardize a better way" doesn't give much to talk about if I don't buy into the issues you have with Javascript and executable code. If you could give a compelling example of a better way that gives the same freedom I would love to hear it. The alternatives I know of all sacrifice something (speed, interactivity, flexibility, development cost) in the name of getting rid of something it seems most people don't have a fundamental problem with (namely sandboxed executable code).
        madez 9y ago
        Oh, I don't want to give all the freedom that JavaScript in the browser gives, and that's the whole point. If we came up with something that allowed the same things, then that would be a pointless exercise. There will be cuts in aspects, some necessary, some intentional. I don't advocate for a better way to have apps on the web, but to have a better app-less web. I'm a bit tired to talk about this topic right now. I'm also repeating myself. I talked a lot about JavaScript on HN recently, so you can read there more, and the surround comments have lots of other perspectives. Not everything has been said. Maybe I'll write up a structured and hopefully complete blog post about it some day soon.
        EgoIncarnate 9y ago
        I will certainly agree that requiring JavaScript unnecessarily should be frowned on and progressive enhancement should be the norm. A least give user the option of taking on additional security risks associated with Javascript (and WebAssembly) or not (edit: where possible).

Yes, but at the cost of: 1. Increased complexity on the server side to handle both cases. 2. Degraded experience on the client side (page reloading for simple actions like upvoting).

madez 9y ago

Then let's standardize generic ways that permit things like upvotes without reloading the page and without executing externally supplied code. :-)

zzzcpan 9y ago
You can do this already with iframes, link targets and :visited for css classes. Using javascript is unnecessary. This technique used to be popular before XMLHttpRequest.
- madez 9y ago
  Thanks for providing a solution. If using JavaScript to achieve this is easier/more efficient/better in some other way that is convincing, then we can think about standardizing better ways to do it. And if it's not better using JavaScript, then it's just an issue of raising awareness about not using JavaScript for it.
  - SquareWheel 9y ago
    Embedding hundreds of iframes into existing pages isn't a viable solution. Consider that a single reddit comment requires at least: upvote, downvote, save, report, hide. Not to mention actually commenting, expanding/collapsing threads, or gilding comments. A thread shows 200 comments by default (500 with Gold). Even 200 comments x 5 features requires a thousand iframes, each of which is embedding a complete document. If you think web performance is bad now...
    - madez 9y ago
      > Embedding hundreds of iframes into existing pages isn't a viable solution. I know I'm repeating myself, but then let's standardize a better way to solve the problem without executing supplied code. JavaScript is not a magic bullet that solves problems that aren't solveable otherwise.
      - EgoIncarnate 9y ago
        You'll have to come up with proof of a better alternative before you'll get agreement from people like me. Javascript and sandboxed executable code may not be a magic bullet, but it's the bullet we have. "Lets standardize a better way" doesn't give much to talk about if I don't buy into the issues you have with Javascript and executable code. If you could give a compelling example of a better way that gives the same freedom I would love to hear it. The alternatives I know of all sacrifice something (speed, interactivity, flexibility, development cost) in the name of getting rid of something it seems most people don't have a fundamental problem with (namely sandboxed executable code).
        madez 9y ago
        Oh, I don't want to give all the freedom that JavaScript in the browser gives, and that's the whole point. If we came up with something that allowed the same things, then that would be a pointless exercise. There will be cuts in aspects, some necessary, some intentional. I don't advocate for a better way to have apps on the web, but to have a better app-less web. I'm a bit tired to talk about this topic right now. I'm also repeating myself. I talked a lot about JavaScript on HN recently, so you can read there more, and the surround comments have lots of other perspectives. Not everything has been said. Maybe I'll write up a structured and hopefully complete blog post about it some day soon.
        EgoIncarnate 9y ago
        I will certainly agree that requiring JavaScript unnecessarily should be frowned on and progressive enhancement should be the norm. A least give user the option of taking on additional security risks associated with Javascript (and WebAssembly) or not (edit: where possible).