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

91–100 of 136 posts

Re: Languages Which Almost Became CSS

#91

Post by kenko »

marcosdumay wrote: post #69
mordocai wrote: post #36

Earlier quoted context omitted.

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…

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.

Re: Languages Which Almost Became CSS

#92

Post by schmudde »

djsumdog wrote: post #23
schmudde wrote: post #9

"HTML is the kind of thing that can only be loved by a computer scientist. Yes, it expresses the underlying structure of a document, but documents are more than just structured text databases; they have visual impact. HTML totally eliminates any visual creativity that a document’s designer might have. — Roy Smith, 1993" Seems like an odd request in 1993. Sure, Prodigy had visual impact, but it was pretty hard to read…

oh man...Prodigy. I remember using my ole 1200 bps modem to load up those .. EGA? VGA graphics? I can't even remember. I do remember my prodigy user ID though.

Yeah, I was a CompuServe guy, but it was pretty innovative and looked great at the time.

Re: Languages Which Almost Became CSS

#94

Post by [deleted] »

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)

[deleted]

Re: Languages Which Almost Became CSS

#95

Post by naasking »

pcwalton wrote: post #85
naasking wrote: post #78

Earlier quoted context omitted.

> Rendering performance (animations, scrolling, etc.) is one of the key reasons why native is perceived to be winning vs. the Web. Except this is an argument against JavaScript driven behaviour, not against a restricted styling language slightly more expressive than CSS. The fact that we would be able to move some of this dynamic behaviour from a general purpose language where optimizing redraw is difficult, to a dom…

> The fact that we would be able to move some of this dynamic behaviour from a general purpose language where optimizing redraw is difficult, to a domain-specific language where optimizing redraw is loads easier would yield performance improvements, not regressions. No, it wouldn't. "Optimizing redraw" isn't difficult, and to the extent that it is it has nothing to do with the expressiveness of CSS.

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 some of the uses of JavaScript over the years? This too seems to be an undeniable yes.

So it seems undeniable that modern browsers would be faster than they currently are on the metrics you criticised them as compared to native apps, which seems to be your primary concern.

And you can claim gzip is good enough to eliminate any space savings a more expressive language would yield, but the fact is people still minify their JS and CSS for significant savings, which means even small differences matter; further, domain specific optimisations have significant effects, and a precompiler could perform advanced common subexpression elimination passes to further compress beyond what gzip could dream of without affecting the semantics your layout.

So theoretically and empirically it seems my point that trading off rendering speed for network speed is not only well motivated, but already settled in my favour.

Re: Languages Which Almost Became CSS

#96

Post by pcwalton »

naasking wrote: post #95
pcwalton wrote: post #85

Earlier quoted context omitted.

> The fact that we would be able to move some of this dynamic behaviour from a general purpose language where optimizing redraw is difficult, to a domain-specific language where optimizing redraw is loads easier would yield performance improvements, not regressions. No, it wouldn't. "Optimizing redraw" isn't difficult, and to the extent that it is it has nothing to do with the expressiveness of CSS.

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 static analysis as Scheme!)

> Do you agree or disagree that such a layout language could supplant some of the uses of JavaScript over the years? This too seems to be an undeniable yes.

Sure, but that's not worth slowing down so many Web sites for.

> And you can claim gzip is good enough to eliminate any space savings a more expressive language would yield, but the fact is people still minify their JS and CSS for significant savings, which means even small differences matter

Sure, but it's not worth trading off the rendering performance.

> a precompiler could perform advanced common subexpression elimination passes

Not with Scheme, it sure can't! You can do those dynamically, but not statically.

Re: Languages Which Almost Became CSS

#97

Post by specialist »

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…

DesignGridLayout is based on canonical design grids.

https://designgridlayout.java.net/grids.html

The heuristics are hand coded.

I created DGL because I wanted visually correct, easy to create UIs. Here are some usage examples. (I probably won't ever design a "fluent API" (method chaining) ever again. A DSL would be better.)

https://designgridlayout.java.net/usage.html

Next time I do interesting UI work, I'll port DGL to that platform. I won't wrestle with constraints solvers again for anything but the most trivial efforts.

Mea culpa: I use Bootstrap for web stuff. Good enough for trivial UIs. Last time I checked, a few years back, I couldn't figure out how to use CSS to align text baselines between columns, or how to space those baselines vertically equally.

Re: Languages Which Almost Became CSS

#98

Post by pcwalton »

panic wrote: post #90
pcwalton wrote: post #64

Earlier quoted context omitted.

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

Why not? Modern JIT compilers generate very fast code.

"Very fast" in this case is not enough for restyling. It is incredibly performance sensitive. A 2x slowdown over the optimized C++ (for example) would be unacceptable.

Re: Languages Which Almost Became CSS

#100

Post by wtbob »

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.

I love Lisp, and I love s-expressions, and I honestly can't viscerally understand why others don't. From listening to my teammates' comments, I think that it has something to do with how they register visual patterns in code. Lisp really does seem to be lots of irritating silly parentheses to them: where I just see sculpted code-shapes, they see a mess of undifferentiated parens and symbols.

I wonder if there really are mental types well-suited to Lisp and types ill-suited to it.

Post reply on HN