Nazca – New GUI for the Web
github.com
github.com
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.
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.
Can you use Mixins without having to import them on every .svelte file?
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.
<html id="b">
<head id="c">
<title id="d">
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.
div.foo#thing {
text: "Foo"
}
<div class="foo" id="thing">Foo</div>
I mean, worst case, give everything an id but don't _output_ it!
%div.foo#thing
FooI also wonder why the author didn't pick up these standard methodologies and continue from there.
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.
Seems like a totally proportional response to a relatively minor issue that's probably easily fixed if someone created an issue for it.
.html {
.head {
.title {
text: A simple Hello World example;
};
};
.body {
.div {
text: Hello world;
};
};
};
[:html
[:head [:title "A simple Hello world example"]]
[:body [:div "Hello World"]]]
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.
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.
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.
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.
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).
So load those files as external, single-language files. Problem solved.
Not worth it.
From the README:
.html {
.head {
.title {
text: A simple Hello World example;
};
};
.body {
.div {
text: Hello world;
};
};
};
%html
%head
%title
A simple Hello World example
%body
#somedivid
Hello world
Requiring enclosing braces and semicolons after every line are unfortunate choices IMO.
I am not good writer :( and can't explain things well. That's why you probably don't like the README. I would really appreciate if someone could help me to write it better.
You should not think of it as new markup language. I wrote it is like CSS, but it is not. That's why comparing it with XAML is not correct. It is not a goal to make markup writing lighter. It is not "look what we can do" either. In nazca every object of the GUI is indeed an object, which can act on its own. The difference - more OOP approach, instead of usual. You should address the objects, like children, parameters of other projects. You can write a class of an object, extend any child class of it and use as many instances as you like. Classes in nazca act as real classes of the JavaScript, and also are useful as classes of the CSS.
About IDs - because it i not intended to be used by IDs (the idea is to never use querySelectorAll()), I used pretty simple mechanism to generate them. Of course we can discuss and change them. I don't want to set them explicitly, like #id to avoid querying them. I will think more of using greater alphabet. Your comments about it are interesting.
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".
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.
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.
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.
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.
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.
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.
Agreed
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?
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.
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.
Seems like a waste of an opportunity.
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)} } ]