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

61–70 of 136 posts

Re: Languages Which Almost Became CSS

#61

Post by pcwalton »

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…

CSS layout is slow enough as it is. Adding all the features you propose here would make the situation far worse.

The fact that CSS layout mostly follows a top-down (and parallelizable!) width assignment phase followed by a botton-up height assignment phase is not something to throw away lightly.

Re: Languages Which Almost Became CSS

#62

Post by Kinnard »

edvinbesic wrote: post #29
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…

There is always Grid Style Sheets[1] if you want to try it out. It is based on the same algorithms as iOS constraint engine[2] AFAIK. Unfortunately it has to compute the constraints using javascript as its not native. [1]: https://gridstylesheets.org/ [2]: https://en.wikipedia.org/wiki/Cassowary_(software)

WebAssembly should be able to help with that, no?

Re: Languages Which Almost Became CSS

#63

Post by pcwalton »

peatmoss wrote: post #22
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.

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…

And such a web would be far slower. Restyling is usually the slowest part of the rendering pipeline in an optimized implementation. Throwing arbitrary tree transformations made with a Scheme interpreter into the mix would be totally irresponsible without looking at what the consequences would be for performance.

Re: Languages Which Almost Became CSS

#64

Post by pcwalton »

patrickmay wrote: post #15
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.

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.

Re: Languages Which Almost Became CSS

#65

Post by pcwalton »

naasking wrote: post #59
_vya7 wrote: post #25

Earlier quoted context omitted.

Maybe not such a shame. Having something (mostly) static like CSS has lots of performance advantages. Imagine the web being even slower than it already is, that's what DSSSL probably would have resulted in.

Stylesheets would be smaller, and only execute slightly slower on the client due to the expansions needed. Trading rendering speed for network speed is a good choice.

Not only do I think the stylesheets would not end up appreciably smaller after gzip, I also disagree with that argument. Rendering performance (animations, scrolling, etc.) is one of the key reasons why native is perceived to be winning vs. the Web. Making the Web even slower at rich interactive apps is not doing the Web any favors.

Re: Languages Which Almost Became CSS

#66

Post by Kinnard »

gagege wrote: post #56
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…

Really, all you need to do is make your own browser and then popularize it.

1 step ahead of you . . . but this staircase seems really long . . .

Re: Languages Which Almost Became CSS

#67

Post by pcwalton »

smitherfield wrote: post #28
_vya7 wrote: post #25

Earlier quoted context omitted.

Maybe not such a shame. Having something (mostly) static like CSS has lots of performance advantages. Imagine the web being even slower than it already is, that's what DSSSL probably would have resulted in.

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.

Re: Languages Which Almost Became CSS

#68

Post by lisivka »

marcosdumay wrote: post #19
agumonkey wrote: post #12

Earlier quoted context omitted.

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.

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.

Re: Languages Which Almost Became CSS

#69

Post by marcosdumay »

mordocai wrote: post #36
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.

Ruby and Clojure are doing decently (though obviously not as popular as say C and Java) and have pretty advanced metaprogramming. For that matter C++ templates are metaprogramming from what I understand, and C macros are a really really primitive form of metaprogramming. Java also has reflection which is metaprogramming-ish. I don't think the problem was metaprogramming.

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 different from Lisp's one, but Ruby's is more similar. Yet, both communities put a hard limit on the amount of "magic" you should use on your programs (where Ruby's limit is way higher than Python's), so it can not become the panacea that it is in Lisp.

Metaprogramming is one of the main selling points of Lisp, the only other being how easy it is to implement. Other languages have other features to show.

Re: Languages Which Almost Became CSS

#70

Post by Animats »

mahyarm wrote: post #53
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…

Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n). I think out of practicality it wasn't adopted. It would be better if both were available, but such is life. http://floriankugler.com/2013/04/22/auto-layout-performance-...

It's used for screen layout in MacOS Lion and Grid Style Sheets.[1] There's also a subdomain that goes faster, and simple layouts should be in that subdomain.

The idea is to get away from programmer-oriented layout input.

Post reply on HN