[HN Gopher] Nazca - New GUI for the Web
___________________________________________________________________
Nazca - New GUI for the Web
Author : qinti
Score : 137 points
Date : 2021-11-03 12:03 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| omneity wrote:
| Once you get past the trivial examples (that every negative
| thread seems to be hung up on), the ideas introduced by Nazca
| seems very cool and novel. This is an approach to building a web
| UI with a single language and shared scope.
|
| I like the approach for encapsulation especially. It makes a lot
| of sense compared to webcomponents for example.
|
| I recommend going through the readme before forming an opinion,
| it builds up on the concepts gradually.
| paxys wrote:
| Cool, yes. Novel, I don't know. It seems to be a mashup of a
| couple templating languages and JS frameworks.
| thibran wrote:
| It's funny to see these web things, that are in the end a "bad"
| reinvention of what a Lisp programmer would do with macros, but
| without anything special. Instead of having macros, they just
| reinvent the wheel again and again...
|
| Nowadays JS is compiled... what a joke. I understand why they do
| it, the result with a JS transplitter is just better for
| everyone, but why on earth do they not use macros? Maybe in 20
| years macros will be the thing, like filter/map has been in the
| last 10 years... who knows.
| orthecreedence wrote:
| Coming from many years in common lisp, I often wonder this.
| With things like coffeescript I felt the syntax didn't add
| much, but you've got the chance to do something great...add
| macros!! Rust is a good example of grafting macros onto an
| existing language, and the JS syntax is even simpler than rust,
| so why has nobody done it in any of the compile-to-JS
| languages?
|
| Seems like a waste of an opportunity.
| bogwog wrote:
| Having separate html/css/js files is a good thing, I don't why
| you'd want to combine them?
| fayten wrote:
| I agree, in fact I wish there was one more layer that separated
| layout from styling. Keep padding, but tear out flex box, grid,
| margin, etc and have a VFL like language instead.
|
| Too be fair flex box and grid are pretty good. I just wish I
| didn't have to sometimes skim through huge CSS or SASS files to
| make layout changes.
| djrockstar1 wrote:
| Angular's flex-layout sort of achieves this? Where you can
| define the layout of the page within the template using flex
| attributes, but still have another file for css.
| Zababa wrote:
| I'm not sure, I think the idea of scoping HTML/CSS/JS at the
| same level is good for development. At least when you think in
| terms of "components", it's easy to see why you would want
| content, styling and behaviour together. Keeping things local
| makes everything easier in my experience.
|
| HTML also has that weird position where you have things like
| <video> or forms, which are not really content but entire
| components, but still lacks lots of things people expect from a
| component library.
| mumblemumble wrote:
| When Windows Presentation Foundation split layout, styling, and
| logic into three separate sets of files, it was a huge win for
| maintainability. I had my share of complaints about WPF, but it
| was never that. It was mostly that I wished the rules for how
| they interacted with each other were easier to understand.
|
| I feel the same way about html/css/jss. It's not the
| fundamental triumvirate that bothers me. And I'm fine with
| their respective syntaxes. My problem is that the semantics of
| the whole system is an ever-growing Gordian knot of accidental
| complexity.
|
| But that problem is very nearly unfixable, so I can't really
| blame anyone for tinkering with more superficial things
| instead.
| jpfed wrote:
| Nazca's include mechanism allows you to separate your code in
| whatever way you find appropriate.
| l30n4da5 wrote:
| It isn't really the fact that it is all in one file that is the
| problem for maintainability, imo, it is that all (html, js.
| css) are incorporated together into a single unit, with no way
| of breaking it up.
|
| Vue puts html, js, and css into the same file with their .vue
| files, and it works great, because they keep those things
| separate _within_ the file. Also, there is the ability to load
| each section from a separate file, as well, which works
| flawlessly.
| IshKebab wrote:
| > and it works great
|
| It works _okay_ , except that it makes all tooling much much
| more complicated because you have to deal with multi-language
| files, and the template is HTML so you get frequent type
| errors (TSX catches those at compile time).
| l30n4da5 wrote:
| > It works okay, except that it makes all tooling much much
| more complicated because you have to deal with multi-
| language files
|
| So load those files as external, single-language files.
| Problem solved.
| mrweasel wrote:
| That shipped has sailed long ago. I don't disagree, and I
| really don't want to work with any technology that mixes HTML
| and JavaScript, but that's not really how modern web frameworks
| view the world.
| rkangel wrote:
| Except that in a lot of modern frameworks that separation has
| gone away - look at React components where the markup and
| styles usually live together.
| l30n4da5 wrote:
| really hate the direction React has gone with that.
| DemocracyFTW wrote:
| Having them separate is not necessarily a good thing. Svelte
| for one collects all the HTML, JS and CSS that you need for a
| given component into a single file (that uses the original
| syntax for each language). You _can_ still draw in code from
| external files, but otherwise your component is just 1 file to
| take care of. Components are largely isolated from each other
| so the `.foobar` class used in one component does not affect
| the `.foobar` used in another.
| lvncelot wrote:
| Vue does the same thing with .vue files.
| pedalpete wrote:
| I wish the original post would have started off with why the
| project exists.
|
| They say "have everything in one file", but is there a problem
| having your JS, CSS, HTML in separate files?
|
| CSS, and to a lesser extent JS isn't limited to a single
| component. Styles are reused across multiple components for
| consistency, so this "reason to exist" breaks right away.
|
| There are enough comments about how people like, or dislike the
| syntax, etc, but it might help to understand the problem the
| creator was trying to solve, before just saying "this won't fit
| my workflow".
| no_time wrote:
| Can't wait until someone writes yet another abstraction layer on
| top of this to keep the chain growing.
| slmjkdbtl wrote:
| "Hey check out this new tool we created called nazcax, it lets
| you use familiar HTML syntax directly in a nazca file! Powered
| by our extensible nazca compiler framework Quran."
| sodimel wrote:
| "Hey check out this new scripting language that I created in a
| calc plugin for the webpages-create-nocode-GUI application
| that's built on top of nazca! you can event write html and
| create beautiful webapps!"
| bussierem wrote:
| Having every layer in the chain also implicitly supporting
| HTML makes this 100% accurate to how things end up
| eventually.
| airstrike wrote:
| I'll make the easiest criticism and just say that if you're
| building something with a stated goal of being "syntactic sugar",
| their hello world example is god awful...
|
| From the README: .html { .head {
| .title { text: A simple Hello World example;
| }; }; .body { .div {
| text: Hello world; }; }; };
|
| Just off the top of my head, compare that with Haml and let me
| know which one you'd rather type: %html
| %head %title A simple Hello World
| example %body #somedivid
| Hello world
|
| ...and that's assuming you couldn't replace Haml's %s with .s to
| match Nazca
| nielsbot wrote:
| One of the great aspects of HAML is that there are no closing
| tags/delimiters.
|
| Requiring enclosing braces and semicolons after every line are
| unfortunate choices IMO.
| zamadatix wrote:
| Seems very much like invoking the age old YAML vs JSON debate.
| You may be surprised what some others prefer.
| Apofis wrote:
| If anybody ever wanted HTML and JS in their CSS files instead,
| then nazca is definitely for you.
| [deleted]
| HelloNurse wrote:
| It seems a case of JSON addiction, or even (since there are
| semicolons) JavaScript addiction.
| WorldMaker wrote:
| Given the later examples it almost seems like trying to merge
| everything into CSS syntax, but then the selectors don't make
| any sense (.html rather than html?) and yeah the way too many
| semicolons also doesn't make any sense (why do you need
| semicolons at the end of {} blocks? I can't think of any
| language that does that).
| tedmiston wrote:
| I literally looked at the hello world examples, asked myself
| "what is this conflated mess?" and scratched my head. Maybe I'm
| just old or missing something here. -\\_(tsu)_/-
| pgt wrote:
| If you want to unify markup, styling and behaviour, Reagent with
| its Hiccup syntax remains the holy grail for me: http://reagent-
| project.github.io/
| tyingq wrote:
| PHP can go one step farther and unify your backend with all
| that too, all into a single glorious file :)
| gmfawcett wrote:
| That sounds too "point-oh" for my tastes, I'll wait for the
| tech to mature. :P
| fao_ wrote:
| <html id="b"> <head id="c"> <title
| id="d">
|
| Ok, those ids are viscerally disgusting and immediately turned
| off any curiosity I had. My own HTML generator managed to
| generate meaningful IDs, why can't they?
|
| Generated HTML should look like handwritten HTML for the sake of
| the poor sod who has to open up the generated files and figure
| out why they do not work, or debug using web dev tools, IMO.
| spoiler wrote:
| I don't understand why they didn't do something like this
| instead: div.foo#thing { text:
| "Foo" }
|
| Generates this: <div class="foo"
| id="thing">Foo</div>
|
| I realise that there's issues with css name collisions, but
| there's different ways that can be resolved by the compiler.
| cabalamat wrote:
| That makes sense -- only give a tag an id if it needs one. It
| only needs one if ti's being referred to somewhere, and when
| that happens the user can give it a name, such as "thing" in
| this example.
| rowanseymour wrote:
| Was thinking the same thing. Or just copy HAML which would
| be... %div.foo#thing Foo
| LastMuel wrote:
| This is how JADE/PUG handled it. And, for anyone that's used
| css, querySelector or jQuery, it seems quite natural.
|
| I also wonder why the author didn't pick up these standard
| methodologies and continue from there.
| davidmurdoch wrote:
| These short IDs are likely generated for performance reasons.
| Meaningful IDs would increase page size quite a bit (not just
| in the HTML, but in the CSS and JavaScript that references them
| as well).
|
| Developers sometimes optimize their critical HTML to fit within
| a tuned initial TCP congestion window to improve performance,
| so this stuff can make a difference.
| ape4 wrote:
| In that case, I hope they'll use esoteric Unicode characters
| for id names to save bytes /s
| Narishma wrote:
| Those will to take more bytes than plain ASCII characters.
| jcelerier wrote:
| Don't both gecko and blink store those as UTF-16 anyways
| ? if so, "a" would take less storage than "aaa" when all
| of [a-zA-Z0-9]+ have been covered
| zamadatix wrote:
| In decoded memory perhaps, the data format in bytes over
| the network is going to be whatever the server/page says
| it is encoded in (utf8 overwhelmingly these days).
| michaelmior wrote:
| These could of course be generated as longer IDs during
| development and shortened for production.
| [deleted]
| naasking wrote:
| > Ok, those ids are viscerally disgusting and immediately
| turned off any curiosity I had.
|
| Seems like a totally proportional response to a relatively
| minor issue that's probably easily fixed if someone created an
| issue for it.
| HelloNurse wrote:
| It's a major issue, and not easily fixed unless the design is
| implausibly suitable (raw IDs in the input imply the absence
| of any ID management).
| ellyish wrote:
| This is very elegant. Glad that you put so much effort into this.
| twobitshifter wrote:
| I actually think this is pretty neat and don't reject the unified
| vision as bad. This does not block you from keeping separate
| classes for styling and inheriting properties, so it can give you
| the same benefits of css. What it looks like it does is keep
| everything in a single organized system without introducing huge
| complexity, or obscuring the underlying model, something most
| frameworks fail at.
| dangoor wrote:
| A lot of the comments here read like folks didn't continue on
| through the readme to get to the class definitions and code
| parts. I think this sort of experiment with a different approach
| is cool.
|
| Personally, I prefer the way Svelte blends HTML/JS/CSS together
| in a file, because it's a smaller abstraction layer than what
| Nazca provides, thus making it clearer how things will end up
| after compilation.
| Jarwain wrote:
| This is the main reason why I liked/chose vue over react at the
| beginning; SFCs felt like a reasonable way to break up widgets
| and minimized the learning curve
| pier25 wrote:
| I adore Svelte, but I still have a separate project for SCSS
| for a number of reasons.
|
| 1) There's always a need for global CSS anyway.
|
| 2) I've found having styles in SFCs only works for very small
| components. Once you're adding JS and HTML, SFCs become a pain
| to navigate. I've been using SFCs in Vue too for 6 years.
|
| 3) Having an old school SCSS project makes it much easier to
| use all SCSS features (eg: mixins) and organize the cascading
| in any way you prefer.
|
| 4) If you have a separate design team, they can work on the
| SCSS in parallel.
| dangoor wrote:
| That makes sense. I just started a new project with SvelteKit
| and Tailwind. I appreciate how Tailwind puts some boundaries
| and defaults around the styling of components, and recognize
| that there are still places where global styling makes sense.
| [deleted]
| dillondoyle wrote:
| I didn't see an example of array?
|
| But it could be useful I think? I'm not sure how would do it
| though, maybe have to make a constructor but the probably wrongly
| written general idea:
|
| .navigation ul [ .li { text: constructor() {return
| generate_from_array_of_data_maybe(render_data_or_something)} } ]
| michaelsbradley wrote:
| The approach is different, but made me think of OJ, which was
| posted to Hacker News way back when:
|
| https://news.ycombinator.com/item?id=6382490
|
| http://ojjs.org/
| liminal wrote:
| Line and block comments in JSON configuration files FTW! Not sure
| when I'd use this project, though.
| willvarfar wrote:
| Any screenshots or demos?
| duiker101 wrote:
| Seems to be a GUI language rather than a library so the demos
| are the pieces of code in the README
| ryanmarsh wrote:
| This reminds me of HAML.
|
| https://haml.info/
| xbar wrote:
| I like the pursuit of beauty present in both.
| gwn7 wrote:
| Good for the author, as I imagine that it must've been a great
| educational experience for them, but I don't really see how this
| would help anybody in the real world.
|
| Seems like it reflects a very subjective way that the author
| wants to implement web apps in.
|
| I mean why should anybody invest so much time to learn
| alternative syntaxes and configurations to replace HTML, CSS,
| Javascript, module bundlers, existing SSR solutions etc, all at
| once??
|
| Every new tech should have a convincing excuse to exist.
|
| We've had the likes of HAML to simplify HTML, CoffeeScript to
| simplify JS, SASS to simplify CSS. These worked well as they
| optionally replaced a small part of the stack and took great care
| not to deviate too much from the underlying tech. They arguably
| had an acceptable cost/benefit ratio. The costs were little, as
| they should have been.
|
| And for the stuff that completely introduced a new world such as
| ELM, Purescript, ClojureScript: ELM brought in established
| functional programming paradigms while at the same time providing
| a sensible framework for the common SPA. Purescript made the web
| accessible to Haskellers. ClojureScript targeted Lispers and made
| the Clojure ecosystem accessible to them in their web apps.
|
| I don't see how I can justify the use of this "language" other
| than the fact that the author "likes it this way". Everything
| seems so arbitrary and the "all in one" approach seems daunting.
|
| Every good developer goes through a "framework building phase"
| which is a very enjoyable and educative process even if the end
| product is mostly useless to anybody else other than the author.
| I think the author is going through theirs. Best of luck.
| ramesh31 wrote:
| >We've had the likes of HAML to simplify HTML, CoffeeScript to
| simplify JS, SASS to simplify CSS. These worked well as they
| optionally replaced a small part of the stack and took great
| care not to deviate too much from the underlying tech. They
| arguably had an acceptable cost/benefit ratio. The costs were
| little, as they should have been.
|
| What's so wonderful about the web as a platform is that, over
| time, each of the technolgies you've mentioned were able to
| actually influence the evolution of the HTML, CSS, and JS specs
| respectively. To the point that now they are all completely
| obsolete. The web has come so far in the last 10 years it's
| insane. With a little bit of transpiling down from the latest
| features, you can now write pure vanilla html/css/js that would
| have required a dozen different libraries and frameworks back
| in the day. This, IMO, is what we should continue striving for.
| gwn7 wrote:
| > With a little bit of transpiling down from the latest
| features, you can now write pure vanilla html/css/js that
| would have required a dozen different libraries and
| frameworks back in the day. This, IMO, is what we should
| continue striving for.
|
| Agreed
| l30n4da5 wrote:
| > To the point that now they are all completely obsolete.
|
| I _heavily_ disagree that SASS is completely obsolete.
| ramesh31 wrote:
| >I _heavily_ disagree that SASS is completely obsolete
|
| I'll die on this hill. PostCSS with transpilation from the
| future CSS spec has completely obliviated the need for SASS
| at this point. Everything it doesn't cover that SASS did
| (i.e mixins, for loops, if/else logic) were objectively
| _bad_ things to be doing in your stylesheets; the entire
| point of CSS is to be completely declarative. With native
| css imports, variables, calc(), and nesting, there 's
| nothing more you need at this point.
| vehemenz wrote:
| There are still plenty of reasons to use SASS. Especially
| if you need big, engineered stylesheets.
|
| Are most people using PostCSS? Are a lot of front-end
| people married to JavaScript-specific tooling? Because
| Tailwind does all the same stuff and works anywhere.
|
| I mean PostCSS is cool, but I don't see how it's actually
| better than alternative tools. It just makes CSS easier
| in one particular aspect, at the expense of others. Like
| pretty much all tools.
| gwn7 wrote:
| > It just makes CSS easier in one particular aspect, at
| the expense of others. Like pretty much all tools.
|
| I agree, but what sets PostCSS apart from other tools is
| its forward compatibility. Which is a reason to opt for
| it for many people, including me.
|
| At the end of the day most people will benefit from
| having vanilla CSS knowledge anyway regardless of any
| layer they prefer to use on top of it. SASS is such a
| layer as well as Tailwind. PostCSS is just tomorrow's
| CSS. It is to CSS what Babel is to Javascript. So using
| PostCSS instead of SASS is comparable to using Babel
| instead of for example CoffeeScript.
|
| If one deems that tomorrow's CSS as it currently stands
| is advanced enough to handle "big, engineered
| stylesheets", then PostCSS may well be all they need. But
| I don't think there is a single right answer here.
| l30n4da5 wrote:
| > But I don't think there is a single right answer here.
|
| Sounds like SASS isn't obsolete if that is the case.
| Saying something is obsolete implies there is _zero_
| reason to use it over some other solution.
| antihero wrote:
| This seems like a step backwards, it's procedural rather than
| declarative, very wordy, seems like it has all of the
| disadvantages of CSS and none of the advantages of anything else
| reilly3000 wrote:
| I personally have never thought to myself "I wish I could write
| everything in CSS" but that's just me.
| otabdeveloper4 wrote:
| I have. This isn't like CSS though.
| tyingq wrote:
| Looks more like "everything in sort-of JSON" to me.
| Eikon wrote:
| From the example: .html { .head {
| .title { text: A simple Hello World example;
| }; }; .body { .div {
| text: Hello world; }; }; };
|
| Seems pretty awful to me...
| diggan wrote:
| In Clojure (hiccup), the idea is similar (lists for HTML) but
| with a nicer syntax. Comparing it, how does this seem as an
| alternative? [:html [:head [:title
| "A simple Hello world example"]] [:body [:div "Hello
| World"]]]
|
| It's simply lists inside lists, with keywords (:html) being
| converted to HTML elements, and second (and the rest) item/s
| being children of whatever came as the first keyword in the
| list.
| hoosieree wrote:
| Hard to compete with any lisp at generating html - html is
| basically just a verbose lisp.
| mmargerum wrote:
| I was sitting here thinking why doesn't the author just use
| reagent? so much nicer and you aren't using yet another DSL
| yakubin wrote:
| The editorialized title is inaccurate. It's not a "New GUI for
| the Web". It's "A new way of creating GUI in the web". There is
| an important difference.
| tedmiston wrote:
| From the readme it sounds like the author has picked up english
| as a second language, so I don't think the misleading title is
| intentional.
| [deleted]
| [deleted]
| KronisLV wrote:
| First off, the idea of having a component in a single file feels
| like a really nice idea, as long as you don't have lots of common
| code.
|
| Secondly, the syntax feels as odd and probably uncomfortable to
| use as AngularJS binding types:
| https://stackoverflow.com/a/35858878
|
| And in my experience, people didn't want to bother with creating
| new subcomponents in it and instead built few large ones just
| because of how uncomfortable it was to use.
|
| I feel like they syntax here could also detract from the overall
| experience somewhat as well.
|
| Instead, why not just write regular HTML files with inline
| <style> and <script> tags with optional comments that would make
| a smart build step perhaps extract some of the styles (e.g. all
| the rules that won't cause layout shift and therefore don't have
| to be blocking and can be a separate file) and scripts into
| separate files, transpile certain functions or patterns where
| needed etc?
| oehpr wrote:
| "And in my experience, people didn't want to bother with
| creating new subcomponents in it and instead built few large
| ones just _because of how uncomfortable it was to use_. "
|
| it speaks to how programmers are people, and subtle ux in a
| programming style will dramatically effect how it is used.
|
| I have no idea if nazca is a good or bad idea, but it clearly
| presents a new UX to create these components, and I can see how
| I might be more willing to use components created in this style
| than in Angulars.
___________________________________________________________________
(page generated 2021-11-03 23:01 UTC)