Show HN: Preprocessor I've been working 4 years now | Hacker News Reader

Show HN: Preprocessor I've been working 4 years now

npmjs.com

78 pointsmopires47 comments

Hey there,

I'm here today to share with you a software I've been working on for 4 years now. I'm not full time dedicated to it, as I need to make a living. My inspiration to develop it came when I started using Sass for real in production. I really appreciated the hierarchy of nesting rules instead of the way CSS vanilla used to do. The obvious nesting rules was easy to read and understand just by looking at. That was something I personally admirated very much. I wondered why there was no HTML preprocessors as revolutionary as there is for CSS and JavaScript. All popular preprocessors for HTML have one thing in common. All replace the angle brackets by something else (usually identation) and then add some functionalities on top of it. If the symbols for markups are a problem to the experience of developing a visual structure, just replacing it for something else doesn't fix the problem. You are just changing the character of marcation for another.

With that in mind, I started Pretty Markup. Not just replacing the clutter of angle brackets by something else, but removing it completely. Very much inspired by Sass. No special characters needed, except by the quotes. The project still in its early stage, but its already useable. I reached a point where it has a stable base to work. Now, I'm plannig the layer of features that will make it usefull and revolutionary as Sass and TypeScript. Its important to note that I didn't started directly in Pretty Markup. I had a previous package called htmlpp-com-github-mopires. Yes, terrible name, but it was a start. Later a decided to make it more professional and with a friendly name.

You can give it a shot by having NodeJS and installing it with:

npm install pretty-markup

I created a syntax hightlighter for VS Code to attract more devs to it. You can use it by searching "pretty markup" on the extensions tab. Now, it's the first one. The next step will be a package to create a basic starter project. Something like the good old create-react-app.

Any feedback, suggestion or even a contribution about anything is very welcome.

Thank you very much for your attention,

Matheus

PS: The package available in runkit is very old(and I don't know how to update it there), I do not recommend you to test there.

Open articleView on HN

I suggest putting a code sample of a page written in Pretty Markup that shows off its features in the README. The documentation is currently somewhat devoid of information about the language itself.

I second this, I have basically no feeling for it other than zooming in a the README gif

Which is super slow. The first 10 seconds or so are just slowly traversing an auto complete menu.

Thank you for the suggestion, I've done something like this in early versions. But removed thinking the gif would be enough.

I'm currently building the documentation

What is the difference between this and Haml or slim?

+1 really curious about the diff. Remind me slim and pugjs

This is a snippet of a article I'll post about it: "[...] popular preprocessors for HTML out there, have one thing in common. They replace the angle brackets, then add some functionalities on top of it. If the symbols of a tag are problems to the experience of developing a frontend, replacing it for something else doesn't fix the problem. Just change the symbol. Pug, Haml, slim, and some others change the angle brackets by indentation or something else. So now, you have to be careful with indentation and not the angle brackets. Please, don’t get me wrong, those are very well developed preprocessors that are also very well maintained by very skilled people. They deliver what they propose. [...]"

But this still doesn't explain what pretty markup does that's different, just that it doesn't use indentation.

Seems like maybe all that's different vs. normal HTML is that it doesn't have angle brackets.

Yes. But it truly doesn't have angle brackets. At the moment, the features that make it different from pure html are its feature tags and config tags. For example !doctype, meta viewport are built in. Stylesheets and javascripts can be attached with feature tags. Such as style and javascript, respectvely. It may seem that is not that much for now, but as more features are added it will be handy and rubust. One of the goals are to deliver a better development experience.

I’ve used something similar quite a long time ago called Jade. Seems to be renamed to Pug. Here’s a nice writeup with some examples (not mine, found the webpage missing examples): https://www.sitepoint.com/jade-tutorial-for-beginners/

Even has highlighting in vscode, and there's a plugin for pugjs snippets.

Pug syntax is whitespace-sensitive though, while this doesn't seem to be, it has closing tags which I prefer.

Also Pug is more of a templating engine, while this doesn't appear to have any interpolation / templating logic stuff.

Overall, it's much less noisy than pug, just by removing the parentheses and commas. But if the objective of this kind of markup is trying to minimize visual noise, removing redundant closing tags (which have inconsistent rules) would be an improvement.

The shorthand for classes/IDs seems like a good idea too, if there's a way to do it that improves readability (and seems less magical to the unfamiliar coder)

Shorthand definitions would be a good feature to be added, but it needs refinement. We need to think carefully about how to implement in a way that would fit gracefully with the syntax and with the developer experience.

Also, if we remove closing markup, the only way to understand if a markup is closed woud be by checking if a new markup is open. That doesn`t seem efficient.

I guess pug's whitespace sensitivity permits a way to quickly tell if a tag is closed.

I'm a fan of higher expressiveness/minimalism, so perhaps I'm just biased in my preference, but I also appreciate how it removes the need to know/care about the inconsistent closing tag semantics of html.

That`s correct. It`s not sensitive to anything. Just open and close tags. It is less noisy that way. Removing the bracktes, not replacing it by something else.

How does it differ from pug (jade), which has existed for about 14 years?

I have answered this in a previous comment. I'll past here for your convinience.

It's a snippet for the post I'll make about this very point.

https://news.ycombinator.com/item?id=41119414

It was flagged

Literally how would anyone get started? No docs or even usage examples, for a new language?

About that... I think I got ahead of myself and forgot about this detail. I'm working on this. And will comment on this post when it's public.

If you use indentation for nesting, the closing tags are superfluous. That’s just one of the reasons so many html/xml template langs have chosen that format.

I came here to say this. Get rid of those closing tags.

But then it would just be pugjs from the looks of it.

It's not identation based. Removing the closing tags would just not close anything. Everything would be immediately nested hehe

Right... It's not identation based. Why remove the close tags?

Having used Jade and YAML and Python extensively, I disagree.

Natural languages have redundancy because they're often used in cases where transmission is imperfect. The redundancy provides enough information to piece the meaning back together even if the distortion is high.

A similar example of redundancy is the check digit on a credit card number. You could save some space by eliminating it, but then simple human error can cost people a lot of time and money.

The same principle applies to programming languages. They most commonly get distorted through copy/paste and through modification in adjacent code. Sometimes those distortions create a result that is syntactically invalid, which is the best case scenario and gives you a chance to piece it back together. But the more flexible your syntax is and the less redundancy it has, the harder it is to recover from errors. The distorted code can look correct.

Closing tags and curly braces give extra redundancy to a language which can allow for better error recovery in the case of distortion. They're the check digits of programming: they're not exciting or flashy, but they provide a layer of safety to sharing and modification.

I personally a prefer a stricter syntax with less redundancy. With a sufficiently fast and accurate compiler, things like indentation issues can be resolved very quickly when there is a copy/paste issue.

How do you propose a stricter syntax without redundancy for something like HTML where the problem domain is (mostly) arbitrarily nested elements?

I think in a nutshell you are saying a developer could accidentally hit tab one too many times. Just test against any visual regressions, it's not hard.

"Just" don't do that is easy to say, but it's better to design the language to make it easy to catch mistakes.

The urge to remove delimiters is the lojban impulse [0] applied to programming languages. It's elegant and clean and impractical.

[0] https://mw.lojban.org/index.php

Read my message again, I'm not saying 'just don't do that'.

"Just test against visual regressions" sounds to me like "just look twice at the code you indented". Did I misunderstand?

What I mean is this code should be tested like any other, using visual testing suites like playwright or cypress.

Got it.

My opinion is that if your answer to a deficiency in the language's syntax is to just test harder you're missing something. Quick feedback loops are essential, and the quickest feedback loop at all is having a syntax where it's immediately obvious to the human looking at the code (before analysis is even run!) when there's a problem.

No not test harder. You should be testing anyway.

Closing tags and curly braces are only redundancy if the compiler/interpreter looks at both them and at the whitespace. I don't think any existing languages do that.

No, they're redundancy either way because both sets of syntactic elements communicate to you.

It'd be even better (in this way at least) if the compiler required they match, but you are also a parser.

That is a very interesting argument and very well presented. It gave me something to think about. Although, have in mind that this is a markup language. It's not a script language where you will make complex logic. It's intended to make visual elements. I do not intend to add logic implementation to it, like a template engine(ifs, loops,...). The incoming features are for visual elements implementations, like built in clip paths configuration.

I see now that the way I present it is vague. In future post I'll improve the presentation of it.

Thank you for you attetion to detail and for the argument. As humans we are prone to error. With that in mind I think this can be a valuable addition to the markups.

Thank you!

I'm not using identation. I'm actually using closing tags with a "/". For example:

table [...] /table

I like the closing tags (others don’t seem to) as they help with visual scanning and auto formatting. Nice project, well done!

Thank you sir. Closing tags are a very good feedback about the domains of a tag.

I don't need it, but upvoting just because of your dedication to the project. It also looks very nice, and the extension is a cherry on top

Thank you for you appreciation! I'm very proud of this project. Thank you for the upvote.

Honestly I always had a soft spot for haml. If someone wrote a haml plugin for React I would be in heaven. It's JSX that is an ugly hot mess in mature codebases, not html.

Reply on news.ycombinator.com