3 ms·

I am not concerned in the least about the direction the web is going in right now. You deride the use of preprocessors and such in other places in this thread,

I am not concerned in the least about the direction the web is going in right now. You deride the use of preprocessors and such in other places in this thread, saying that there's a lot of people sinking resources into that, so I have to ask you: do you consider it a hack that you code in Clojure, or Java, or Haskell, or C, instead of coding in assembly? Is it a loss of resources that people are working on compilers for these languages? Is it a hack to code in assembly instead of directly emitting machine code? If the current web stack is the unintended result of a one-night stand between modern C++ and VB6, what is x86-64? The biggest differences between current web technologies and the above analogies are: - Stuff built on top of current web technologies hasn't been under development for nearly as long as stuff built on top of machine code. - The basis here (HTML/CSS/JS) is actually relatively simple for someone who knows nothing about the web to get started with, to build something they can interact with quickly. The biggest obstacles to using it properly even as a basis to build new tools and abstractions on top of have been, IMO, limitations in CSS (though with absolute positioning even those have been worked around effectively in tools like GWT) and primitive drawing, and flexbox and related developments + canvas have started to clear the most glaring of those issues up. “You can't fix the latter using any combination of JavaScript, HTML and CSS, no matter how big a number you put after them.” Big words. I will give you a challenge: come up with an idea, and I posit folks will come up with a way to implement it on top of these “broken models”. In short, I have no idea how you're reaching the conclusions you're reaching, or what it is that makes what's there now not a “portable assembly language”. But regardless, without presenting clear ideas on what a better path would be, I'm concerned your complaints aren't truly useful—and are also needlessly difficult to understand. Complaints about the stack aren't new. Improvements are—and there are plenty of people making them, albeit layered on top of what's there.

Silhouette 13y ago
You deride the use of preprocessors and such in other places in this thread Strictly speaking that's probably true, but I'd like to be clear that I'm not really deriding the idea of preprocessors, but rather the need to use preprocessors to make up for weaknesses in the underlying technology that shouldn't be there. Any time you start talking about a build process, you're talking about introducing (and subsequently managing) overheads. If adding that extra step is a big win for some other reason, the overhead is worth it. But if adding that extra step just brings you up to where everyone else was in the first place, your underlying platform isn't good enough. Put another way, I think it's crazy how often I find a potentially interesting library for building a modern web page/app, but then the getting started page starts with something like "First install package management library P and with that get dependency management tool D, then create configuration file F, featuring dependencies A, B and C, run setup script S to install those dependencies and create scaffolding S', and now you have a complete project ready to go that includes only 3 levels of directory hierarchy and 17 files to start you off so you can follow the 'Hello, world' tutorial." That is an absurd amount of hassle just to get something going in a quick experimental project and see whether it's actually any good, and it amplifies the problems already caused by having so much fragmentation and NIH syndrome in front-end development today. Stuff built on top of current web technologies hasn't been under development for nearly as long as stuff built on top of machine code. That's a fair point, but I suggest to you that there is a flip side: when we build new tools today we also have the wisdom of hindsight. We have several decades of general software development experience to draw on that the guys building early tools in languages like C and the guys who developed the first GUI libraries didn't. And this is really the heart of my problem with the current situation: we don't seem to be paying any attention to those lessons, or the flashing neon signs that developers who went before us installed to warn us never to tread this path again. I will give you a challenge: come up with an idea, and I posit folks will come up with a way to implement it on top of these “broken models”. I almost rose to that challenge, but then I realised it was missing the point. You can write a word processor in assembler, and some people have, but just because it's possible, that doesn't mean it's an efficient way to do it with the other tools and techniques we have available today. But regardless, without presenting clear ideas on what a better path would be, I'm concerned your complaints aren't truly useful The problem with modern web development is that instead of trying to build tools that are comparable with the best we've developed elsewhere, learning from the greater experience of other software developers and DBAs and sysadmins and UI designers and all the rest, we're taking it as axiomatic that we have to build on what's already there. Why should we do that? The amount of resources being thrown into new web standards and languages and preprocessors and tools across the industrial as a whole is vast, and it already includes several projects on a scale not very far from building the kind of "portable Web assembly language" or "powerful, flexible, extensible layout model" concepts I'm talking about. Just think about all the new rendering engines, JS runtime environments, X-to-JavaScript compilers, X-to-CSS compilers, and so on that have been built in recent years. I don't claim to be nearly as creative or smart as, for example, the people who developed tools like SASS. But such tools have been developed, and have been very successful, and we can learn a lot from that both in terms of what is possible and how much easier good tools can make the development process. We can also learn a lot from where even those tools haven't been as successful, because as preprocessors they are inherently limited by their target format.

Silhouette 13y ago

You deride the use of preprocessors and such in other places in this thread Strictly speaking that's probably true, but I'd like to be clear that I'm not really deriding the idea of preprocessors, but rather the need to use preprocessors to make up for weaknesses in the underlying technology that shouldn't be there. Any time you start talking about a build process, you're talking about introducing (and subsequently managing) overheads. If adding that extra step is a big win for some other reason, the overhead is worth it. But if adding that extra step just brings you up to where everyone else was in the first place, your underlying platform isn't good enough. Put another way, I think it's crazy how often I find a potentially interesting library for building a modern web page/app, but then the getting started page starts with something like "First install package management library P and with that get dependency management tool D, then create configuration file F, featuring dependencies A, B and C, run setup script S to install those dependencies and create scaffolding S', and now you have a complete project ready to go that includes only 3 levels of directory hierarchy and 17 files to start you off so you can follow the 'Hello, world' tutorial." That is an absurd amount of hassle just to get something going in a quick experimental project and see whether it's actually any good, and it amplifies the problems already caused by having so much fragmentation and NIH syndrome in front-end development today. Stuff built on top of current web technologies hasn't been under development for nearly as long as stuff built on top of machine code. That's a fair point, but I suggest to you that there is a flip side: when we build new tools today we also have the wisdom of hindsight. We have several decades of general software development experience to draw on that the guys building early tools in languages like C and the guys who developed the first GUI libraries didn't. And this is really the heart of my problem with the current situation: we don't seem to be paying any attention to those lessons, or the flashing neon signs that developers who went before us installed to warn us never to tread this path again. I will give you a challenge: come up with an idea, and I posit folks will come up with a way to implement it on top of these “broken models”. I almost rose to that challenge, but then I realised it was missing the point. You can write a word processor in assembler, and some people have, but just because it's possible, that doesn't mean it's an efficient way to do it with the other tools and techniques we have available today. But regardless, without presenting clear ideas on what a better path would be, I'm concerned your complaints aren't truly useful The problem with modern web development is that instead of trying to build tools that are comparable with the best we've developed elsewhere, learning from the greater experience of other software developers and DBAs and sysadmins and UI designers and all the rest, we're taking it as axiomatic that we have to build on what's already there. Why should we do that? The amount of resources being thrown into new web standards and languages and preprocessors and tools across the industrial as a whole is vast, and it already includes several projects on a scale not very far from building the kind of "portable Web assembly language" or "powerful, flexible, extensible layout model" concepts I'm talking about. Just think about all the new rendering engines, JS runtime environments, X-to-JavaScript compilers, X-to-CSS compilers, and so on that have been built in recent years. I don't claim to be nearly as creative or smart as, for example, the people who developed tools like SASS. But such tools have been developed, and have been very successful, and we can learn a lot from that both in terms of what is possible and how much easier good tools can make the development process. We can also learn a lot from where even those tools haven't been as successful, because as preprocessors they are inherently limited by their target format.