3 ms·
" However you represent it, you still need a way to say that you want a 1px border, a certain font, links that get bigger when you mouse over them and so on. Th
by boucher 19y ago
" However you represent it, you still need a way to say that you want a 1px border, a certain font, links that get bigger when you mouse over them and so on. There's a whole model there which can certainly be abstracted into something else, but that something else won't necessarily be simpler (it will, however, be non-standard)."
The thing is, is that really what people who are building applications need to figure out? Yes, they probably need access to changing these properties, but the vast majority of what you are doing when you are writing an actual application on the web is far more complicated then setting a few class properties on some divs.
It isn't so much about compressing this, as it is about throwing out this broken architecture. HTML/CSS are great technologies for page layout. In fact, I have a perverse love for them which I am unable to explain, let alone understand. But they suck when it comes to dynamic, application like behaviors. We need a new technology. And yes, while it won't be a w3c or whatwg standard, if its open source, who cares? I, for one, am tired of relying on browser manufacturers to get things done.
- gruseom 19y agoHmm, we're talking in the same general space but miscommunicating on details, so this discussion may need to wait until you guys can provide specifics of what you're working on. But let me try to clear up a couple points. The thing is, is that really what people who are building applications need to figure out? Yes, they probably need access to changing these properties You answered your own question. Yes, they need this, along with a lot of other things. That complexity is intrinsic to making a web app and therefore is hard to completely abstract away. Of course I do not exaggerate the importance of div borders. My point was that even the sexp your colleague cited as a counterexample contains a lot of information - not just browser nastiness or crud, but useful information, which any model you try to replace HTML/CSS/JS with will still need to represent. It isn't so much about compressing this When I said "compression" I didn't mean it literally, as in gzip, but metaphorically. A good abstraction is a kind of logical compression inasmuch as it replaces a complex, detailed model with a simpler one that contains the same information. It does this by throwing out non-essential details (like duplication). Now, if your goal is to build a general abstraction ABC on top of HTML/CSS/JS, ABC must be much simpler in order to justify its learning curve and the fact that it's nonstandard. (By "nonstandard" I simply mean unfamiliar.) That means you're going to have to find a lot of "noise" to throw out. My skepticism is based on the fact that I don't see a lot of such noise in the general case. A thing can be messy and yet still difficult to abstract over. But I'm not saying it can't be done, and good for you if you can do it. The approach we take with Parenscript is more modest, I think. We're not building universal abstractions for web apps, just for our own. That means we can abstract away from anything we don't need, whether or not it's needed by others. That and the fact that Lisp gives us a homogeneous way of representing all the HTML/CSS/JS pieces are two very big wins. Is it enough to get non-Lisp-geeks to use it? Probably not. But I don't think that's why most hackers take up something like Lisp in the first place.
- tlrobinson 19y agoI think the problem is we have two very different solutions to two different problems. Parenscript seems great for the things you're describing, but those are the things I happen to not be interested in. I'll be sure to let you know when we have something more to show, I'd be interested to hear your opinions of it.
- gruseom 19y agoI'll keep an eye out for it. Good luck.