3 ms·

I thought it's the article about yet another JavaScript framework indeed.

by tnzk 5y ago

deleted 5y ago
[deleted]
mananaysiempre 5y ago
You know, thinking about it seriously, I’m not sure I agree with this sentiment, as reasonable as it seems on the surface. I do think the Web Platform makes a pretty bad (foundation for a) UI toolkit, at least judging from the results. I think the amount of awkwardness in JavaScript is just plain unreasonable. I’m also disappointed by how badly the practices of the modern Web accomodate, well, viewing static text and images retrieved over the Internet. Various JavaScript libraries and approaches seem to pass by so fast I get dizzy if I look. (The last point would probably disappear were I to fully immerse myself in Web programming, but I just don’t like it enough for that.) And yet. It seems that the people making all these frameworks and producing unjustifiably heavy blobs of JavaScript in order to display a photo... Are gradually encountering and solving, in a practical context and with real-world feedback, a lot of genuinely difficult problems—problems which often have only been considered in an academic context, and then not with an overabundance of results. It’s not that they go out looking for difficult problems to solve—unlike academics. They frequently don’t even realize the difficulty or the existence of the problem at first. It’s just that they start with a reasonably complete solution for a small problem area, go right to the boundary, and push. Pretty soon the boundary reaches things that were previously only attacked with Grand Generalized Solutions, found hard, and left unsolved. Yet they need them solved, so they push further. The flood of frameworks and best practices occurs because they are iterating. This process produces warts. I mean, of course it produces warts. It cannot help but produce warts. In a setting that also prizes backwards compatibility, some of those warts survive long enough to become functionally immortal, and so the survivors accumulate even if most warts are eliminated very quickly. Eventually we reach a point where we can only look back at a five-meg Opera executable and weep. This process also means that some of the new best practices are practically indistinguishable from the old ones. However, that is not in itself a condemnation: a lot of people changing their minds can very well happen a function at a time, a default at a time, even a function name at a time. Some of those changes—maybe even most of those changes—are still noise and passing fads. But they are fads of a specific kind—they are generally not sticky: because iterating is the (social) norm, whole industries and schools of thought don’t get founded around a single supposedly universal solution, and giant edifices of millions of lines and man-centuries of effort don’t get erected around a suboptimal approach (see: XML). As fads go, I’d say these are pretty mild. So what are some of the hard problems the Web people are solving or found themselves having solved? Native code generation for dynamic languages. (Tracing JITs pretty much won, from what I can see, yet it seems that nobody expected that, not even the Self people that did much of the foundational work in an academic context before.) Ergonomics of a fully asynchronous programming environment, up to and including system calls. (Again, cooperative concurrency seems to have pretty much won here, yet it wasn’t that long ago that the BeOS approach of preemption and shared memory seemed a plausible solution for responsive UIs. While people were already doing cooperative threads when the 6502 was the new hotness, my machine has IndexedDB but neither scheduler activations nor transactional memory.) Model that can represent most of the meaningful organizational semantics in most of the documents. (The problem isn’t inventing a model, the problem is obtaining enough data to converge on the right one. HTML5 is a resounding success in this respect; from what I can see most of the other document preparation or processing systems either had the document author code a bespoke structure, fell back to presentation details, forced everyone to adjust their documents to match the limitations by administrative mandate, were basically unusable, or all of the above.) Declarative, non-Turing-complete styling that’s still flexible enough to make following the semantic model above feasible and even pleasant. (I like XSLT and dislike most templating, but CSS selectors feel so much more carefully designed than XPath. I suspect having to do efficient and even incremental implementations from the start has something to do with it. I still want a neat mathematical model, like maybe tree transducers, to tell me what I should and shouldn’t include in a styling language.) Practical, interactive reflowable text layout that can do modestly non-trivial typesetting. (TeX can do some things better but basically can’t do cutouts at all without hardcoding sizes, and it’s a language powerful enough you can basically only execute it. Roff does much less. Everything else either requires babysitting by a human when changing layout widths or would make a typographer from half a millenium ago cringe.) Resolution independence including on pretty low-resolution devices without fuzziness or glitches and with support for zooming in while preserving in the layout. (The CSS “pixel” is a hack but the approaches in native app ecosystems are absolutely infested with much worse hacks. I wonder how many people on Earth understand the rounding code in a major browser.) Understandable, even intuitive GUI conventions for (extremely) untrusted applications. (It starts with powerboxes but ends with very subtle tricks like a timer on the “Open” button. Still no petnames for some reason.) Applications that work offline yet can be used immediately without a user-visible installation step. (Turns out you just had to make the online case the default one and get it wrong a couple of times, and you can give people enough of a framework that they are able to make the major effort required to get it working if they have the motivation.) Graphical user interfaces that are general enough to do almost anything yet are not a maze of twisty little assignments and repaint calls. (I’ve been watching the progress in FRP since about 2010, and while the Web variations are all pretty kludgey, they’re still a damn sight better than everything I’ve seen atop a native UI toolkit. I get the impression XAML might be a contender but haven’t been able to find a description of how it deals with the difficult stuff; it’s also purely presentational from what I understand.) Each of these purported solutions has flaws and can be disputed, and I’m sure people can point me to prior work that’s more principled or does some aspects better (please do!). My point is that all of the questions are very difficult, mostly unrelated to the Web’s natural monopoly position, and yet for every one of them the Web ecosystem approach of dumb but dauntless iteration has done the state of the art a lot of good.

I thought it's the article about yet another JavaScript framework indeed.

by tnzk 5y ago

I thought it's the article about yet another JavaScript framework indeed.

deleted 5y ago

[deleted]

mananaysiempre 5y ago

You know, thinking about it seriously, I’m not sure I agree with this sentiment, as reasonable as it seems on the surface. I do think the Web Platform makes a pretty bad (foundation for a) UI toolkit, at least judging from the results. I think the amount of awkwardness in JavaScript is just plain unreasonable. I’m also disappointed by how badly the practices of the modern Web accomodate, well, viewing static text and images retrieved over the Internet. Various JavaScript libraries and approaches seem to pass by so fast I get dizzy if I look. (The last point would probably disappear were I to fully immerse myself in Web programming, but I just don’t like it enough for that.) And yet. It seems that the people making all these frameworks and producing unjustifiably heavy blobs of JavaScript in order to display a photo... Are gradually encountering and solving, in a practical context and with real-world feedback, a lot of genuinely difficult problems—problems which often have only been considered in an academic context, and then not with an overabundance of results. It’s not that they go out looking for difficult problems to solve—unlike academics. They frequently don’t even realize the difficulty or the existence of the problem at first. It’s just that they start with a reasonably complete solution for a small problem area, go right to the boundary, and push. Pretty soon the boundary reaches things that were previously only attacked with Grand Generalized Solutions, found hard, and left unsolved. Yet they need them solved, so they push further. The flood of frameworks and best practices occurs because they are iterating. This process produces warts. I mean, of course it produces warts. It cannot help but produce warts. In a setting that also prizes backwards compatibility, some of those warts survive long enough to become functionally immortal, and so the survivors accumulate even if most warts are eliminated very quickly. Eventually we reach a point where we can only look back at a five-meg Opera executable and weep. This process also means that some of the new best practices are practically indistinguishable from the old ones. However, that is not in itself a condemnation: a lot of people changing their minds can very well happen a function at a time, a default at a time, even a function name at a time. Some of those changes—maybe even most of those changes—are still noise and passing fads. But they are fads of a specific kind—they are generally not sticky: because iterating is the (social) norm, whole industries and schools of thought don’t get founded around a single supposedly universal solution, and giant edifices of millions of lines and man-centuries of effort don’t get erected around a suboptimal approach (see: XML). As fads go, I’d say these are pretty mild. So what are some of the hard problems the Web people are solving or found themselves having solved? Native code generation for dynamic languages. (Tracing JITs pretty much won, from what I can see, yet it seems that nobody expected that, not even the Self people that did much of the foundational work in an academic context before.) Ergonomics of a fully asynchronous programming environment, up to and including system calls. (Again, cooperative concurrency seems to have pretty much won here, yet it wasn’t that long ago that the BeOS approach of preemption and shared memory seemed a plausible solution for responsive UIs. While people were already doing cooperative threads when the 6502 was the new hotness, my machine has IndexedDB but neither scheduler activations nor transactional memory.) Model that can represent most of the meaningful organizational semantics in most of the documents. (The problem isn’t inventing a model, the problem is obtaining enough data to converge on the right one. HTML5 is a resounding success in this respect; from what I can see most of the other document preparation or processing systems either had the document author code a bespoke structure, fell back to presentation details, forced everyone to adjust their documents to match the limitations by administrative mandate, were basically unusable, or all of the above.) Declarative, non-Turing-complete styling that’s still flexible enough to make following the semantic model above feasible and even pleasant. (I like XSLT and dislike most templating, but CSS selectors feel so much more carefully designed than XPath. I suspect having to do efficient and even incremental implementations from the start has something to do with it. I still want a neat mathematical model, like maybe tree transducers, to tell me what I should and shouldn’t include in a styling language.) Practical, interactive reflowable text layout that can do modestly non-trivial typesetting. (TeX can do some things better but basically can’t do cutouts at all without hardcoding sizes, and it’s a language powerful enough you can basically only execute it. Roff does much less. Everything else either requires babysitting by a human when changing layout widths or would make a typographer from half a millenium ago cringe.) Resolution independence including on pretty low-resolution devices without fuzziness or glitches and with support for zooming in while preserving in the layout. (The CSS “pixel” is a hack but the approaches in native app ecosystems are absolutely infested with much worse hacks. I wonder how many people on Earth understand the rounding code in a major browser.) Understandable, even intuitive GUI conventions for (extremely) untrusted applications. (It starts with powerboxes but ends with very subtle tricks like a timer on the “Open” button. Still no petnames for some reason.) Applications that work offline yet can be used immediately without a user-visible installation step. (Turns out you just had to make the online case the default one and get it wrong a couple of times, and you can give people enough of a framework that they are able to make the major effort required to get it working if they have the motivation.) Graphical user interfaces that are general enough to do almost anything yet are not a maze of twisty little assignments and repaint calls. (I’ve been watching the progress in FRP since about 2010, and while the Web variations are all pretty kludgey, they’re still a damn sight better than everything I’ve seen atop a native UI toolkit. I get the impression XAML might be a contender but haven’t been able to find a description of how it deals with the difficult stuff; it’s also purely presentational from what I understand.) Each of these purported solutions has flaws and can be disputed, and I’m sure people can point me to prior work that’s more principled or does some aspects better (please do!). My point is that all of the questions are very difficult, mostly unrelated to the Web’s natural monopoly position, and yet for every one of them the Web ecosystem approach of dumb but dauntless iteration has done the state of the art a lot of good.