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.
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.
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.
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.
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.
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.
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.
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).
That would be extremely gross and wouldn't even work in some cases. E.g. a Javascript linter may rely on actual files in actual paths. And you can't do that for IDEs so you'll have to do a ton of extra work to get them to work with it.
It maybe just that I am a millennial and lack experience, but for me component based approach is much better than all 3 in separate file, for both maintainability and code reuse.
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.
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.
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.
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).
It says a lot about how they approach code generation that makes it a giant waving red flag, for me personally. A rule of code generation is "don't output internal structures unless it's necessary for runtime functioning". This isn't necessary, since no reference is being made to them, which it knows in advance. It tells me that they don't care about the output, which means that if I use it for a long term big project the output is likely to not be human readable, which actually means a whole lot when you are debugging it in-browser!
"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!"
"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."
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.
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.
While I think this is a step in the right direction to address the ugly and verbose nature of HTML, Pug in a .svelte file is by far the nicest way to write html I’ve experienced.
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.
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
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.
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.
I always have a “styles” folder with scss in my Sveltekit projects, and use scss in my Svelte components. Svelte auto-preprocessor makes it pretty effortless.
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.
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
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.
>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.
>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.
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.
> 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.
> 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.
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.
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...
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).
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. ¯\_(ツ)_/¯
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?
"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.
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.
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?
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".
The syntax reminds me of kotlin’s html dsl a bit. I personally like languages with curly braces for scope because it plays nice with vim. You can quickly select everything in the current scope by typing viB, for instance.
Thank you for your comments. I am glad someone liked it, sorry to hear someone did not understand (or did not accept) it. You are all are awesome!
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.
94 comments
[ 0.26 ms ] story [ 127 ms ] threadToo 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.
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.
I mean, worst case, give everything an id but don't _output_ it!
I 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.
https://haml.info/
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?
https://news.ycombinator.com/item?id=6382490
http://ojjs.org/
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
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.
From the README:
Just off the top of my head, compare that with Haml and let me know which one you'd rather type: ...and that's assuming you couldn't replace Haml's %s with .s to match NazcaRequiring enclosing braces and semicolons after every line are unfortunate choices IMO.
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.
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)} } ]
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.
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".
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.