31–40 of 42 posts
Earlier quoted context omitted.
True, but almost no one is writing HTML anymore. So if I'm anyway post-processing my tsx / jsx / vue / whatever files, I might was well use a language that's great. As for adding a layer to what devs needs to learn - that's why I don't generally use this at work. In those situations you often need to pick the most common tools and not the best tools.
> almost no one is writing HTML anymore JSX?
Skimming over the README page, it reminds me of PHP from back in the day.
The example has left me with a strong impression I should avoid this and HAML. That syntax frightens me.
He was working on a web app and we deduced he hated HTML, because 1) he liked HAML, and 2) the two most technical people spent a lot of time cleaning up bugs he authored.
That whole project was a mess so that never achieved high priority status. I would have distrusted HAML anyway, but that experience certainly punctuated that feeling.
This is not an arena where an impedance mismatch has any payoff worth paying. You're working on a web app. Use HTML and CSS (SCSS if you must)
Earlier quoted context omitted.
sure, I guess lighting the house with fire also works!
In my experience, adding a layer between you and what you are doing adds a potential layer to every bug, and a layer to what new developers need to learn. That needs a lot of justification.
It was dog slow and it had some really stupid api you had to use if you needed to handle nesting that you couldn’t determine until runtime (on account of the no closing tags—use case: rendering a tree of data in a streaming-records sort of situation, not exactly a super-rare need).
There was a faster implementation, several times faster… but it achieved that in no small part by ditching the bits of the api that allowed you to manipulate nesting, so I couldn’t use it.
That project made me hate crap like this. HTML isn’t scary, hard, or even (in a halfway modern editor) slow to write, FFS. I’ll never ever pick this sort of templating language when it’s my choice.
Earlier quoted context omitted.
Because JSX is just document.createElement() with syntax sugar. If Haml has an equivalent api, there should be a way to implement something similar.
I don't understand, I thought document.createElement() is independent of JSX. JSX works just as well in Deno/Bun/Node.js without DOM functions.
Earlier quoted context omitted.
Because JSX is just document.createElement() with syntax sugar. If Haml has an equivalent api, there should be a way to implement something similar.
I don't understand, I thought document.createElement() is independent of JSX. JSX works just as well in Deno/Bun/Node.js without DOM functions.
Although to be fair, it's hard not to name a Haml library "Hamlet" ^_^
That's great; Haml is one thing I like most when doing web development on Ruby/Rails. The only thing I don't like about this implementation is the blocks with inline code: - if user != nil { %strong The user exists - }
- else if other_condition
%span other content
- else
%span another bit of content
That's great; Haml is one thing I like most when doing web development on Ruby/Rails. The only thing I don't like about this implementation is the blocks with inline code: - if user != nil { %strong The user exists - }
I use Haml in my web framework, I use syntax_suggest [1] to count the missing pairs so I can insert them automatically at the end of the block. It would probably not be too difficult to do the same thing in Go. 1. https://github.com/ruby/syntax_suggest/blob/main/lib/syntax_...