4 ms·

It amazes me that we're now at the point of standardizing sticking array references inside strings and yet we're still not having a serious discussion about wha

It amazes me that we're now at the point of standardizing sticking array references inside strings and yet we're still not having a serious discussion about what comes after HTML.

andrewstuart2 12y ago
What's wrong with a human-readable serialization format?
- lorddoig 12y ago
  Nothing - I was talking about this: <input name='kids[1]' value='Thelma'> <input name='kids[0]' value='Ashley'>
  - andrewstuart2 12y ago
    Whoa. I missed that. Probably by clicking the link to the serialization algorithm. That's bad. Really, really bad.
    - libria 12y ago
      What structure are we suggesting? This?: <inputgroup name='kids'> <input value='Thelma'> <input value='Ashley'> </inputgroup>
  - arcatek 12y ago
    I guess that it's because at first, it was assumed that it was one of the servers jobs to parse such structures based on their names. Since these same servers failed to establish a consensus (Django using "a=1&a=2" as array, whilst php uses "a[]=1&a[]=1", for example), someone has to start ...
chc 12y ago
It amazes me that you think we could have a serious discussion about what comes after HTML when essentially nobody is seriously considering replacing HTML. HTML is what it is, nothing else is what HTML is, and HTML is going to be around a good long while.
- aplummer 12y ago
  it'll be like when they replaced paper with the internet...
- Silhouette 12y ago
  It amazes me that you think we could have a serious discussion about what comes after HTML when essentially nobody is seriously considering replacing HTML. Of course we are. There are numerous new technologies competing to replace the role we have shoe-horned HTML into playing -- look at all the different templating technologies now in development, for example, and things like Web Components. There are also numerous technologies for marking up semantic content and/or styling such data for presentation. The only thing that isn't changing right now is that we're still stuck with eventually reducing these alternatives to plain HTML for display in browsers, which is about as good an idea as insisting we reduce all styling to CSS and all programming to JavaScript. It's a historical accident, it's resulted in widespread dependence on tools that are nowhere near fit for the purposes they are now asked to serve, but there is so much momentum in the industry that building tools to accommodate the weaknesses as well as possible is the preferred strategy over completely starting over. See also: Almost everything about programming ever.
  - lorddoig 12y ago
    Fully agreed. A low(ish)-level, non-JS API to the sea of DOM "primitives" inside blink/gecko/webkit/etc. suitable for targeting in an FFI-like manner by any language is the standard I'd like to see. We don't need 3 languages: it's all there in C++ classes and C structs. I've been writing a lot of ClojureScript/React lately and with that I only really touch HTML to include CSS and scripts. It's pretty glorious, highly productive, and makes a very strong case for opening up lower levels to allow new paradigms to evolve - with this set-up, HTML and JS only get in the way. The browser is now (almost) an OS in a VM and, imho, the sooner we start treating it like that the better.
nly 12y ago
QML?

It amazes me that we're now at the point of standardizing sticking array references inside strings and yet we're still not having a serious discussion about what comes after HTML.

andrewstuart2 12y ago

What's wrong with a human-readable serialization format?

lorddoig 12y ago
Nothing - I was talking about this: <input name='kids[1]' value='Thelma'> <input name='kids[0]' value='Ashley'>
- andrewstuart2 12y ago
  Whoa. I missed that. Probably by clicking the link to the serialization algorithm. That's bad. Really, really bad.
  - libria 12y ago
    What structure are we suggesting? This?: <inputgroup name='kids'> <input value='Thelma'> <input value='Ashley'> </inputgroup>
- arcatek 12y ago
  I guess that it's because at first, it was assumed that it was one of the servers jobs to parse such structures based on their names. Since these same servers failed to establish a consensus (Django using "a=1&a=2" as array, whilst php uses "a[]=1&a[]=1", for example), someone has to start ...

chc 12y ago

It amazes me that you think we could have a serious discussion about what comes after HTML when essentially nobody is seriously considering replacing HTML. HTML is what it is, nothing else is what HTML is, and HTML is going to be around a good long while.

aplummer 12y ago
it'll be like when they replaced paper with the internet...
Silhouette 12y ago
It amazes me that you think we could have a serious discussion about what comes after HTML when essentially nobody is seriously considering replacing HTML. Of course we are. There are numerous new technologies competing to replace the role we have shoe-horned HTML into playing -- look at all the different templating technologies now in development, for example, and things like Web Components. There are also numerous technologies for marking up semantic content and/or styling such data for presentation. The only thing that isn't changing right now is that we're still stuck with eventually reducing these alternatives to plain HTML for display in browsers, which is about as good an idea as insisting we reduce all styling to CSS and all programming to JavaScript. It's a historical accident, it's resulted in widespread dependence on tools that are nowhere near fit for the purposes they are now asked to serve, but there is so much momentum in the industry that building tools to accommodate the weaknesses as well as possible is the preferred strategy over completely starting over. See also: Almost everything about programming ever.
- lorddoig 12y ago
  Fully agreed. A low(ish)-level, non-JS API to the sea of DOM "primitives" inside blink/gecko/webkit/etc. suitable for targeting in an FFI-like manner by any language is the standard I'd like to see. We don't need 3 languages: it's all there in C++ classes and C structs. I've been writing a lot of ClojureScript/React lately and with that I only really touch HTML to include CSS and scripts. It's pretty glorious, highly productive, and makes a very strong case for opening up lower levels to allow new paradigms to evolve - with this set-up, HTML and JS only get in the way. The browser is now (almost) an OS in a VM and, imho, the sooner we start treating it like that the better.

nly 12y ago

QML?