Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Languages Which Almost Became CSS

eager.io

Post reply on HN
Print view View original

121–130 of 136 posts

Re: Languages Which Almost Became CSS

#121

Post by wtbob »

unexistance wrote: post #113
wtbob wrote: post #102

Earlier quoted context omitted.

What burns me up is that CSS was supposed to allow site authors to have sensible defaults for their pages while enabling me to override them, and yet when I set a dark theme in Firefox all hell breaks loose. Honestly, the web was better end-user experience for me on links in a terminal: I was able to read text and submit forms, and that's all I really need.

You can do that (of sort) in Firefox by Preference | Content | Colors * change the Text & Background colors * uncheck system colors * always override

Yeah, but the problem is that modern pages are written in such a way that that almost always displays garbage. I tried to do it for a few weeks, but it was terrible looking.

Re: Languages Which Almost Became CSS

#122

Post by marcosdumay »

kenko wrote: post #91
marcosdumay wrote: post #69

Earlier quoted context omitted.

When I see people talking about Closure, I don't see them talking about the power they get from metaprogramming. It's almost the opposite, people talk about the safety of FP, and power from Category Theory. For C++ templates, you get that impression and multiply by a few googols. Now, Ruby and Python communities do claim to gain power from metaprogramming. I can say that Python metaprogramming is something completely…

What people talk about category theory w/r/t Clojure? Since it has almost no type system to speak of, I'd be very curious to know what in the world they're on about. Macros and the repl were, to me, the best part of clojure.

I see people talking about monads and applicatives all the time. I don't know Clojure, but I got the impression it has a powerful implicit type system.

Re: Languages Which Almost Became CSS

#123

Post by amelius »

Animats wrote: post #27

Layout should have been constraint-oriented, not procedural. You should be able to express "Bottom of this box is adjacent to top of that box", and such. All those constraints go into a constraint engine, and a layout is generated. This is something a WYSIWYG editor can generate. To get a sense of how this could work, try sketch mode in Autodesk Inventor (there's a free 30 day demo) You can specify that a point must…

> Layout should have been constraint-oriented, not procedural.

The problem is that there isn't a universal set of constraints that satisfies everybody's requirements. For procedural specs, it only has to be Turing complete to make everybody happy.

Re: Languages Which Almost Became CSS

#124

Post by TheCoelacanth »

lisivka wrote: post #68
marcosdumay wrote: post #19

Earlier quoted context omitted.

My take is that metaprogramming does not scale to teams. Or maybe it's just the historical artifact that everybody claims to be, and if the PDP-10 supported a lisp environment, things would be different. But if I had to bet, I'd bet on metaprogramming not scaling.

Metaprogramming scales very well. Every high-level program + compiler is metaprogram for assembler code.

That has a much higher barrier of entry, though. If I work on a project written in Blub, I won't be able to do any metaprogramming unless I can get everyone else to adopt my Blub++ compiler. If the software is written in Lisp, all I have to do is get it through a code review.

In effect, it's not really scaling; it's being limited to the small portion of developers who work on compilers.

Re: Languages Which Almost Became CSS

#125

Post by talideon »

pcwalton wrote: post #64
patrickmay wrote: post #15

Earlier quoted context omitted.

The engineering management that prevented Scheme in the browser should never be forgiven: https://brendaneich.com/2008/04/popularity/

Scheme in the browser would have been fine. Scheme in the hot path of every single restyle, not so much.

I don't follow you. If, say, browsers used Scheme rather than JS, they wouldn't be any slower. If a CSS-equivalent used s-expressions but was otherwise CSS, that's just syntax.

Re: Languages Which Almost Became CSS

#126

Post by talideon »

agumonkey wrote: post #12
Grue3 wrote: post #11

DSSSL looks amazing. Truly a shame it didn't catch on. Maybe we'd have a client-side Lisp instead of Javascript too.

When I die, my first question to god will be 'sir, why the hate on lisp?'. I expect the answer to involve testing of some kind.

Here's your answer: https://xkcd.com/224/

Re: Languages Which Almost Became CSS

#128

Post by smitherfield »

pcwalton wrote: post #67
smitherfield wrote: post #28

Earlier quoted context omitted.

Well, slower and then faster. Virtual selectors mean that CSS is now also Turing-complete (in a horrible, horrible way). And DSSSL would've been able to handle much or maybe even all of what's currently handled by Javascript.

CSS is only Turing-complete in pathological cases. Pathological cases do not make a good basis for policy decisions. In reality, the loss in performance from losing the style sharing cache alone would probably swamp any gains you'd get from DSSSL.

The point is virtual selectors and using Javascript for styling both have very poor performance characteristics, and both are A. ubiquitous and B. hacky kludges driven by the excessively limited nature of CSS as originally designed.

I'm probably out of my depth here, but what do you mean by the style sharing cache? I mean, any kind of file can be cached by the browser, including Javascript. And presumably browsers could've implemented optimizations (with or without the aid of hinting annotations) to identify those DSSSL functions that need only be evaluated once.

(BTW, like the author of the article seems to, I actually think that PSL looks like the best of the CSS alternatives he lists).

Re: Languages Which Almost Became CSS

#129

Post by wolfgke »

girvo wrote: post #117
peatmoss wrote: post #22

Earlier quoted context omitted.

Can we have a do-over on the web? I've seen (and even nominally participated) in something of a resurgence of Gopher as something of a shadow web for nostalgia-addled geeks. Gopher isn't an awesome protocol, but I love anything that recaptures the spirit and decentralized nature of the old web. At my curmudgeon-iest I like to imagine we carve off our own web where S-expressions reign, there is no Google, and a millio…

When I was 6 years old, in 1996, my parents gave me a book about "Cyberspace" to go along with our dial-up internet connection (on our Pentium 100mhz Windows 95 computer!). This book showed me Gopher, and MUDs, and changed my life! I wish I could remember the name of it, it was a bright yellow cover with a superhero on it, I think. I miss Gopher, in a rose-tinted glasses nostalgia-driven way

> I wish I could remember the name of it, it was a bright yellow cover with a superhero on it, I think.

Could it be Computer Lib/Dream Machines by Ted Nelson:

Cover of the 1974 edition: http://blogs.brandeis.edu/sarahw/files/2011/03/cover1.jpg

Front cover of the 1987 edition (in yellow): https://www.amazon.co.uk/Computer-Lib-Dream-Machines-Tempus/... (sorry, I have no image of the back cover, but I have both editions in my book shelf: Also the 1987 edition shows a superhero on its back cover (cover of Dream Machines)).

EDIT: If you want to order a reprint of the 1st edition (very difficult to get): Ted Nelson sells them again: http://hyperland.com/LibPage

Re: Languages Which Almost Became CSS

#130

Post by naasking »

pcwalton wrote: post #96
naasking wrote: post #95

Earlier quoted context omitted.

You've seemingly ignored the main thrust of my point in order to quibble over what I meant by optimising redraw. Seems dishonest at best. Do you agree or disagree that a domain-specific layout language with would be faster to render and animate than a general purpose programming language interacting with the DOM? This seems like an undeniable yes. Do you agree or disagree that such a layout language could supplant so…

> Do you agree or disagree that a domain-specific layout language with would be faster to render and animate than a general purpose programming language interacting with the DOM? This seems like an undeniable yes. No. I don't believe this is true. With CSS as a declarative language, we can do global optimizations that are much harder to do than with a general programming language (especially one that's as hostile to…

DSSSL is not Scheme, it's a domain-specific language, which solves nearly all of your objections that aren't conjecture. Domain-specific languages are obviously much more amenable to optimization. Such a stylesheet language can be trivially cache JIT compiled stylesheets, and because they're more expressive, you'd see more reuse across pages, and possibly even across sites. The bandwidth savings are non-linear.
Post reply on HN