4 ms·

> HTML (or whatever standard we come up with) can be expanded to add the needed features I think it is hubris to think we can ever build a spec with all the n

> HTML (or whatever standard we come up with) can be expanded to add the needed features I think it is hubris to think we can ever build a spec with all the needed features. > JavaScript is used to lock us in, exactly what the web shouldn't do. While I agree the web shouldn't lock us in I would like to understand how you think JavaScript does that?

madez 9y ago
I don't think it is possible to have a spec thats always contains all the latest functionality. But that is also not necessary. The better the spec, the more problems we can solve completely. I don't think we can always support the newest latest advancement to solve the latest obscure problem, but I think it's no problem to wait a period, even if it were months or years, for it to be standardized and supported in browser. The delay is not a nuisance nor a cost without any benefit. We maintain the open trustable web by doing that. We have already a pretty good idea of what functionality we need. For example, we can look at what common JavaScript frameworks solve, and think about what we should standardized from that. Nobody did that so far, but we totally could, and should.
- iovrthoughtthis 9y ago
  Waiting months and years for features that your site or app depends on is unacceptable. > We have already a pretty good idea of what functionality we need. For example, we can look at what common JavaScript frameworks solve, and think about what we should standardized from that. Nobody did that so far, but we totally could, and should. And once we have captured those concept, what then? Where do we mine the new concepts, designs, behaviours that will need to be introduced to the spec and implemented by each browser vendor individually?
  - madez 9y ago
    > Waiting months and years for features that your site or app depends on is unacceptable. If we do a thorough job now on extending the code-less web, I find it hard to think of sites that couldn't be realized then _and_ shouldn't be a native program in the first place. I simply don't want a web that has place for "apps". For multiple reasons random websites shouldn't have the possibility to make the visitors system execute supplied code. Yes, some people don't agree with that, but they have usually motives for that which I cannot agree with like withholding code or control from users or tracking them. If you have a good reason why there should be apps in the browser, then I'd love to hear it, though. The _example_ suggestion to look at existing framework is just a shortcut to not redo work, and to use already existing knowledge. If someone has an idea of what functionality should be supported we can discuss and standardize it. We had lots of technology completely independent of JavaScript. There is a lot of movement in the JavaScript ecosystem because a lot of ecosystem needs to be developed and there are big companies pushing for it, because they need it to monetize their users, but thats it. JavaScript isn't that important.

madez 9y ago

I don't think it is possible to have a spec thats always contains all the latest functionality. But that is also not necessary. The better the spec, the more problems we can solve completely. I don't think we can always support the newest latest advancement to solve the latest obscure problem, but I think it's no problem to wait a period, even if it were months or years, for it to be standardized and supported in browser. The delay is not a nuisance nor a cost without any benefit. We maintain the open trustable web by doing that. We have already a pretty good idea of what functionality we need. For example, we can look at what common JavaScript frameworks solve, and think about what we should standardized from that. Nobody did that so far, but we totally could, and should.

iovrthoughtthis 9y ago
Waiting months and years for features that your site or app depends on is unacceptable. > We have already a pretty good idea of what functionality we need. For example, we can look at what common JavaScript frameworks solve, and think about what we should standardized from that. Nobody did that so far, but we totally could, and should. And once we have captured those concept, what then? Where do we mine the new concepts, designs, behaviours that will need to be introduced to the spec and implemented by each browser vendor individually?
- madez 9y ago
  > Waiting months and years for features that your site or app depends on is unacceptable. If we do a thorough job now on extending the code-less web, I find it hard to think of sites that couldn't be realized then _and_ shouldn't be a native program in the first place. I simply don't want a web that has place for "apps". For multiple reasons random websites shouldn't have the possibility to make the visitors system execute supplied code. Yes, some people don't agree with that, but they have usually motives for that which I cannot agree with like withholding code or control from users or tracking them. If you have a good reason why there should be apps in the browser, then I'd love to hear it, though. The _example_ suggestion to look at existing framework is just a shortcut to not redo work, and to use already existing knowledge. If someone has an idea of what functionality should be supported we can discuss and standardize it. We had lots of technology completely independent of JavaScript. There is a lot of movement in the JavaScript ecosystem because a lot of ecosystem needs to be developed and there are big companies pushing for it, because they need it to monetize their users, but thats it. JavaScript isn't that important.