
Pylon – Declarative layout primitives for CSS and HTML - sgottit
https://almonk.github.io/pylon/
======
Vanderson
I enjoy seeing other people's solution, but since I really learned the power
of grid, most of this is overdone with flex.

As an example, here's how you can make a vstack with grid.

    
    
      vstack {
        display:grid;
      }
    

It's ridiculously simple and clean, works with all the elements without extra
wrappers, no margins, no cleaning up trailing spaces, etc... add spacing class
using "grid-gap" and it's the near perfect solution.

The hstack example is more complicated, because you simply have to choose
widths, there is no getting around this, even with flexbox. (unless you want
to totally give up control of the layout to "auto".)

The spacing classes are clever, and I may adopt some of this method. (I use
grid gap, I only have 2 sizes) With the "Spacers" example, a width of 1fr
works using grid.

Flex beats grid with some natural overflow capabilities (row wrap), but other
than that, flex is not great for this kind of thing.

Since there's only a few examples, I suspect this person will be adding more
in the future.

Edit: For declarative things like this, I think there should be one
assumption. I use vertical in web interfaces. This means one less option to
remember. (ie, by default everything is vertical)

Edit2: With an unknown number of items, flex is probably preferable for
horizontal items for simple columns. But that is only if you don't care about
the widths of the columns too much as well.

~~~
aldoushuxley001
Only problem with grid vs flex is browser support. I opt for flex still
because it's got better support.

~~~
Vanderson
Since the topic is "new framework", I would not advise investing in a system
that is not ideal long term just because of a very minor support percent
difference today. (looks like 6% of the world based on caniuse.com, but your
audience may vary of course)

The benefit of an assumption like "everything by default is vertical", then
the few people without grid support, but with flex, will have a "mostly" ok
display.

Also, it's not hard to have a fallback to flex for horizontal items. (the only
place it would really matter)

~~~
ysavir
I feel like this would actually be one of the strengths of using a framework.
I can abstract away my own styling to the framework, and the framework can
upgrade from flexbox to grid without requiring me to change any of my own
code.

~~~
Vanderson
Yep, I agree, seems like we are on the same page. I made my own framework
based on my specific uses, so I even get to control when the fallbacks are
removed, and deal with any of the fallout if there's issues.

I kind of think that at one point, everyone that works a lot with front end
web development should make their own framework. It helps you learn to make
long term decisions, deal with design iterations where you have lots of wide
spread use of older systems and many other things that help you make wiser
decisions in day to day interface design. But also it can help you see where
things like Bootstrap are helpful and where it is not.

------
hn_throwaway_99
I like this, but my 20 years in web dev can't help but chuckle. Remember when
tables were declared evil for layout, so we had the shit show of trying to use
CSS floats for everything, so then we added flexbox, and then grid, and here
is a nice set of elements that is basically, well, somewhat less useful than
tables for layout.

Don't mean to bash the poster, I just think it's interesting in the
"everything old is new again" vain.

~~~
ziroshima
I work on an older project with some folks that never got the memo about
tables being evil for layout. In my experience, they've actually been quite
easy to work with. Granted, we develop for a fixed screen width. Why were
tables declared evil?

~~~
shaki-dora
One answer reveals itself by just switching two lines around:

> Why were tables declared evil? > Granted, we develop for a fixed screen
> width.

Personally, I was always more disturbed by the anti-semanticism of the layout
use of tables. But I guess at some point the web developer community just
really stopped caring about such issues. Or at least that's my takeaway of the
common atrocity of style attributes on individual elements that css-in-js
approaches frequently produce.

~~~
jandrese
I think the people really pushing for the Semantic Web kind of gave up. You
hardly ever hear that term anymore.

I guess the value proposition of "You can add a whole bunch of complexity to
your webpage that won't affect what people see so robots can scrape your page
easier" didn't really resonate with developers. Also, the proposals I saw were
much too granular and focused on people writing scientific papers on the web.
It wasn't a good mesh for the "garbage" web, which is like 99% of everything.

~~~
detaro
"Semantic Web" and using the semantically correct tags for HTML aren't really
the same thing.

------
joncfoo
Wow. So many kill-joys in this thread.

I think the project is neat. It certainly is an opinionated way of doing a
layout and it reads quite nicely. If CSS classes were provided as an
alternative I think the project might have more adopters.

Good work :)

~~~
oblib
Most of the critics seemed to be about pita caused by layout methods in
general when rendering them on variable size screens, and not necessarily the
Pylon methods themselves.

I agree with you, I think this is clean and easy to use.

Personally, I've stuck with Bootstrap for quite awhile now. It's not perfect
but it's pretty good, well documented, and I work to keep it simple. So I
don't really use a lot of what Bootstrap does and that's why this project
appeals to me.

------
erichurkman
Reminds me very much of XUL, Mozilla's XML-based language for UI.
[https://developer.mozilla.org/en-
US/docs/Mozilla/Tech/XUL](https://developer.mozilla.org/en-
US/docs/Mozilla/Tech/XUL)

In a prior life I developed a slew of XUL apps, including a full-suite medical
record system and billing system. It had its quirks, but for a developer-heavy
(and design-light) firm it was a great way to build standard, predictable, and
accessible UIs.

------
sametmax
Fun idea. The naming is weird as pylon used to be a python web framework but
since it's not going to have any chance to become popular, overriding it seems
alright.

~~~
philshem
I don’t know. Any package name that contains the string _py_ makes me assume
it’s python.

~~~
jermaustin1
I felt the same way, I was thinking this was some sort of rendering engine to
use with python to generate html layouts

------
pier25
The resulting HTML is not great, but the dev experience looks super nice.

Maybe we need to introduce HTML transpilers now :)

~~~
lioeters
I've been building and using various forms of HTML transpilers for several
years, as part of a build step or "JIT" during server-side rendering.

The main advantage I see is the ability to extend HTML to have
layout/templating functions, building up a simple DSL for frontend devs and
editors. Since the target userbase is already familiar with HTML syntax, it's
easy to learn and gives them "super powers" \- for example, an <include> tag
that imports another HTML file/partial.

Another use case I've used in a number of sites/applications: chaining a
Markdown parser, an HTML transpiler, and a React renderer for the HTML "AST".
Among other things, it renders internal links <a> as <Link> components of the
router.

And the rabbit hole goes deep: the XML/HTML syntax is actually able to
represent "programs" in a Lisp-like manner. If the angle brackets are too
noisy, one can use Jade/Pug syntax to generate the same AST.

In the end, the traspiler should render the result in standards-compliant
HTML. This Pylon project doesn't transpile anything, so the result contains
undefined tags which the browser treats as HTMLUnknownElement [0]. The bottom
line though, is that it works - and I've seen numerous projects in the wild
taking advantage of this behavior.

I'd also like to mention the posthtml project [1]. I haven't used it myself,
but a generic HTML transpiler has great potential in my opinion.

[0] [https://developer.mozilla.org/en-
US/docs/Web/API/HTMLUnknown...](https://developer.mozilla.org/en-
US/docs/Web/API/HTMLUnknownElement)

[1]
[https://github.com/posthtml/posthtml](https://github.com/posthtml/posthtml)

~~~
ben509
> And the rabbit hole goes deep: the XML/HTML syntax is actually able to
> represent "programs" in a Lisp-like manner.

XML was always a poor man's s-expression.

And for all the sins of SGML, tags lend themselves beautifully to templating
because they can represent code as data just as Lisp does.

------
manifestsilence
Very cool, but I'd like to point out that unless/until this gets very popular
to where Google changes their practices, it wrecks certain SEO perks (though
so do a lot of fancy practices). Google still really likes plain old HTML
primitives like <OL> or <UL> for lists, <TABLE> for tables, <P> for paragraph.
Their featured snippets appear to be capable of extracting info that isn't in
that form and bumping it to the top of results, but to prefer not to. My $.02
from starting to learn that game.

------
nwienert
Why have the alignment done relative to the direction of the stack? I’ve
wondered the reason for this with Flexbox as well.

It’s very hard to remember and unintuitive. My guess is something to do with
responsiveness?

To me, alignX and alignY (with an align shorthand) are always clear. And the
amount of times I’m changing between the two is nearly 0 so far in a large
app.

------
ggurgone
The intent is nice, in fact this is what React Native for Web does as well
with the difference that accessibility and semantics are preserved because JS
comes to the rescue.

That said for pure layout stuff I actually think that this library is cool.
<view> is totally fine.

<py-view> (or a sexier prefix) would even be valid HTML

------
DigitalVerse
I think this seems pretty cool. I can see using it for all sorts of projects
with minimalist needs, e.g. quick prototyping, interview coding assignments,
admin consoles.

------
oneplane
You must construct additional Pylons!

------
pvinis
SwiftUI should go more the jsx/HTML way. Not the other way around!

~~~
yoz-y
Why? I think both approaches are valid. SwiftUI separates data from
representation. jsx+css is comparable. Pure HTML always contains some
representation so the boundary is less clear.

------
dmitriid
This most likely breaks accessibility especially in lists.

But it does look nice :)

------
uhryks
So basically you're abusing the fact that (modern) browsers treat unknown tags
more or less as divs and built a small CSS framework with these names.

I understand how that it can feel familiar to Swift devs, and also realized by
reading the source that the upside of using unknown tags means they don't have
any base style that you'd have to override.

But really, you're breaking all HTML semantics and your markup is not
accessible. It could work as a set of React/Vue/Whatever components or even
Web components (probably the best way to achieve what you're trying to do),
but as bare HTML it doesn't.

~~~
masklinn
> So basically you're abusing the fact that (modern) browsers treat unknown
> tags more or less as divs and built a small CSS framework with these names.

The spec allows custom elements[0] and pretty much requires this behaviour.

> you're breaking all HTML semantics and your markup is not accessible.

Calling the markup non-accessible is defensible[1], but it doesn't break HTML
semantics in any way.

[0] [https://html.spec.whatwg.org/multipage/custom-
elements.html#...](https://html.spec.whatwg.org/multipage/custom-
elements.html#autonomous-custom-element)

[1] though it wouldn't be more accessible as a stack of divs and the custom
element can be aria-tagged[2], in the browsers supporting it it's also
possible to use _customised_ elements but here there's little of interest

[2] [https://html.spec.whatwg.org/multipage/custom-
elements.html#...](https://html.spec.whatwg.org/multipage/custom-
elements.html#custom-elements-autonomous-drawbacks)

~~~
matt-tingen
Custom element names must contain a hyphen for forwards-compatibility, and
these do not.

[https://html.spec.whatwg.org/multipage/custom-
elements.html#...](https://html.spec.whatwg.org/multipage/custom-
elements.html#valid-custom-element-name)

------
coldtea
This looks great!

------
heyplanet
This has issues:

    
    
        <list>
            <hstack spacing=s>
                <div class="icon"></div>
                <text>Westminster</text>
                <spacer></spacer>
                <text>0.5 miles</text>
            </hstack>
            ....
    

It is more complex then it needs to be, it puts the styling into into the
html, it kills all semantic meaning and pollutes the global namespace of
element names.

It should be:

    
    
        <my-cities>
            <my-city>
                <city-name>Westminster</city-name>
                <city-distance>0.5 miles</city-distance>
            </my-city>
            ....
    

And then simply style the custom attributes to your liking via css. If these
"primitives" would use classnames instead of element names, their styles could
be added like this:

    
    
        <my-cities class=pylon-list>
            <my-city class=pylon-hstack>
                <city-name>Westminster</city-name>
                <city-distance>0.5 miles</city-distance>
            </my-city>
            ....

~~~
Waterluvian
Are those custom elements just divs by default or do you need to define them
somewhere?

~~~
folkrav
Modern browsers indeed treat unknown elements as equivalent to divs, but it's
officially undefined behavior, up to implementation.

~~~
mixmastamyk
Just tried in firefox and as mentioned above they are not block elements but
inline:

    
    
        <foo>foo</foo>
        <bar>bar</bar>
        <div>div1</div>
        <div>div2</div>
    

Results in:

    
    
        foo bar
        div1
        div2

~~~
folkrav
You're right, they are indeed considered inline elements, not blocks. My bad.

