25 ms·

I think much of JS's churn has been the problem that the UI primitives (HTML) are unsuitable to what people want to do. When you can't even vertically center s

I think much of JS's churn has been the problem that the UI primitives (HTML) are unsuitable to what people want to do. When you can't even vertically center something without reading a bunch of web pages that tell you something like six different techniques, you can imagine that people are going to make a library to do make it easy to do. But since the foundation is crap, and good API design is actually hard, the result is not very good. So someone tries to fix it later, and runs into the same fundamental problems. I think JS the language is in better shape, but even then it is hampered by poor decisions early on. (Integer arithmetic done with double-precision floating point underneath the hood? And it supports bit twiddling, but only if it is really an integer and not a floating point number? And implicit conversions? What could go wrong...) But it is also hampered by other problems. I used WebWorkers recently to compute normals to large amounts of triangles on think, rather than transferring them over the network. In any normal language, I'd add a mutex around the data and spin up some worker threads. But in JS I can either copy the data, or give it away and that thread can't access it again. Since I need the triangle data and don't want the hassle of giving it away and then having the WebWorker give it back again (along with the normals), and then having to manage putting it in the right spot, as well as what happens if I need to access triangle data that's currently being processed, this is a major pain. I understand that the WebWorker design makes it impossible for the browser tab to hang on a deadlock or have all the fun threading errors, but as a programmer, JS is the one language that forces poor performance on me. So you can imagine someone like me, but with more influence, saying, "hey, we need a redesign to fix this." But since the previous designers presumably knew how all other languages work and rejected that approach, the redesign probably won't really fix the problem, for similar reasons why we didn't get WebPThreads the first time around.

zackmorris 8y ago
I agree with pretty much all of what you said. One thing I might change though, is that I'd prefer a copy-on-write (COW) metaphor for WebWorker and SharedArrayBuffer, similar to how Clojure state works. So you'd pass an array by value, but there would be no performance penalty unless values are mutated. I'd also like to eliminate shared state between threads and switch to channels like how Go or Erlang work. These should also be COW. I feel that HTML/CSS is an evolutionary dead end. People think in terms of tables when they do desktop publishing. So forcing them to translate to CSS and back is a task for compilers, not humans. Most people working in web development today are too young to remember that this was all a solved problem in the 80s with WYSIWYG. We let the asynchronous nature of the internet determine the architecture of our markup, which was a mistake in hindsight. I'd vote to rearchitect the web to be synchronous and run under a single-threaded runtime that makes no distinction between front and back end. Then let the runtime handle representational state transfer, a bit like Rsync but for the DOM. This would work like virtual memory (so the developer wouldn't have to worry as much about where state resides) and executation would block until a remote procedure call (RPC) is lazily evaluated deterministically without timeout or having to remain always connected. Then with that prerequisite implemented, we could revisit fluid layout in a formal way, derived from first principles. This might mean transpiling things like SCSS variables to non-turing complete grammars (context-free grammars) like CSS. I'm a little foggy on the terminology for this so someone please correct me if I have it wrong. In other words, we should be able to derive the position of our elements from other positions. So we should have a markup language like: elementX.center.x = body.center.x elementX.width = body.width/2 myX = elementX.right elementY.left = myX + 1 But this would only be processed in one-shot mode. I think a markup like this could be created on top of HTML/CSS but it could be difficult due to quirks. Without basic metaphors like these, web development can never move from being a craft to a field. It will forever be reduced to hand waving and having to drink the kool-aid. Which is fine for now, but will add increasingly more friction as the web development market gets more saturated.
lkrubner 8y ago
"I think much of JS's churn has been the problem that the UI primitives (HTML) are unsuitable to what people want to do." I said the same when I wrote "The Problem With HTML": Just to offer some perspective about where I’m coming from, I’ll start by saying that I think of these as tools that made it easy for beginners to be productive: Hypercard Visual Basic (obviously I mean the classic versions, before .NET. The stuff in the 1990s was genius) Adobe Flash Adobe Dreamweaver I spent 1995 learning HTML and putting together simple websites. I was thinking this is something I’d like to do professionally. In 1996 my father and I went to a demo in New York City, where Adobe was introducing PageMill, their Web page creation software. My father was impressed. My dad wasn’t in the tech industry, but he was pretty smart about technology trends. He said, “Anyone who knows HTML just lost their job. This will replace the need to know any of the underlying technologies.” But that turned out to be wrong. Even now, in 2017, most companies building Web software still rely on individuals to hand-write their frontend code. Indeed, from the point of view of business productivity, everything has been going in the wrong direction. http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html What is curious is that the companies that have the money and resources to roll out something better than HTML have not done so. The biggest surprise here is Adobe, which owns Flash, which many people thought of as the future of the Web circa 2004. Why didn't Adobe roll out new basic network protocols to replace HTML, and perhaps also replace IP and TCP? I don't know. They had the resources to do it and instead they did nothing but stand around and watch their most important asset die.

zackmorris 8y ago

I agree with pretty much all of what you said. One thing I might change though, is that I'd prefer a copy-on-write (COW) metaphor for WebWorker and SharedArrayBuffer, similar to how Clojure state works. So you'd pass an array by value, but there would be no performance penalty unless values are mutated. I'd also like to eliminate shared state between threads and switch to channels like how Go or Erlang work. These should also be COW. I feel that HTML/CSS is an evolutionary dead end. People think in terms of tables when they do desktop publishing. So forcing them to translate to CSS and back is a task for compilers, not humans. Most people working in web development today are too young to remember that this was all a solved problem in the 80s with WYSIWYG. We let the asynchronous nature of the internet determine the architecture of our markup, which was a mistake in hindsight. I'd vote to rearchitect the web to be synchronous and run under a single-threaded runtime that makes no distinction between front and back end. Then let the runtime handle representational state transfer, a bit like Rsync but for the DOM. This would work like virtual memory (so the developer wouldn't have to worry as much about where state resides) and executation would block until a remote procedure call (RPC) is lazily evaluated deterministically without timeout or having to remain always connected. Then with that prerequisite implemented, we could revisit fluid layout in a formal way, derived from first principles. This might mean transpiling things like SCSS variables to non-turing complete grammars (context-free grammars) like CSS. I'm a little foggy on the terminology for this so someone please correct me if I have it wrong. In other words, we should be able to derive the position of our elements from other positions. So we should have a markup language like: elementX.center.x = body.center.x elementX.width = body.width/2 myX = elementX.right elementY.left = myX + 1 But this would only be processed in one-shot mode. I think a markup like this could be created on top of HTML/CSS but it could be difficult due to quirks. Without basic metaphors like these, web development can never move from being a craft to a field. It will forever be reduced to hand waving and having to drink the kool-aid. Which is fine for now, but will add increasingly more friction as the web development market gets more saturated.

lkrubner 8y ago

"I think much of JS's churn has been the problem that the UI primitives (HTML) are unsuitable to what people want to do." I said the same when I wrote "The Problem With HTML": Just to offer some perspective about where I’m coming from, I’ll start by saying that I think of these as tools that made it easy for beginners to be productive: Hypercard Visual Basic (obviously I mean the classic versions, before .NET. The stuff in the 1990s was genius) Adobe Flash Adobe Dreamweaver I spent 1995 learning HTML and putting together simple websites. I was thinking this is something I’d like to do professionally. In 1996 my father and I went to a demo in New York City, where Adobe was introducing PageMill, their Web page creation software. My father was impressed. My dad wasn’t in the tech industry, but he was pretty smart about technology trends. He said, “Anyone who knows HTML just lost their job. This will replace the need to know any of the underlying technologies.” But that turned out to be wrong. Even now, in 2017, most companies building Web software still rely on individuals to hand-write their frontend code. Indeed, from the point of view of business productivity, everything has been going in the wrong direction. http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html What is curious is that the companies that have the money and resources to roll out something better than HTML have not done so. The biggest surprise here is Adobe, which owns Flash, which many people thought of as the future of the Web circa 2004. Why didn't Adobe roll out new basic network protocols to replace HTML, and perhaps also replace IP and TCP? I don't know. They had the resources to do it and instead they did nothing but stand around and watch their most important asset die.