Thanks, confusion about the application and the intended use cases seems to be a common issue among other comments.
Initially thought it was an addon (or JS lib) that allowed for using Ruby as an embedded client-side scripting language that would parse in-line Ruby in the HTML.
Clearer once I realized it was closer to PHP or similar language usages.
Second also to the recommendation about a quick definition of ERB (Embedded RuBy). Had to look it up.
A few practical examples of what an actual user might want to do with HTML + ERB could be helpful.
- Client characteristics customization
- Previous use history customization
- The database Create, Read, Update, and Delete cycle using Herb
- A basic Content Management System example
- A basic e-commerce example
- A basic RESTful API example
ERB is a server-side templating language. It's akin to PHP, Jinja for Python, JSP (Java), ASP.NET Web Pages, etc.
What these do is let you do things like turn a collection of objects into a the HTML for a table and send that over the wire. The client then just has time to display the table and not assemble it from e.g. JSON. ERB and similar allow you to build dynamic sites without using any Javascript at all.
To a first-order approximation, any dynamic site that does not use React or Angular will use a templating language like ERB.
This explanation makes me a bit sad.
> What these do is let you do things like turn a collection of objects into a the HTML for a table and send that over the wire. The client then just has time to display the table and not assemble it from e.g. JSON.
I'm sorry, I guess?
Typo aside, I did try to capture the essential difference of a server-side templating engine vs. how many people build using "modern" web stacks.
Yeah, this what makes me sad. Your premise is that SPA is the default for web development and you imply server side rendering is not “modern”.
Disclaimer: I don't like SPAs, and I think the "modern" web stack is a niche set of technologies that are being widely overused. (This is why I put "modern" in quotes.)
But I have worked with enough engineers schooled since React became popular to know that the "modern" Web stack basically is SPAs everywhere.
Incidentally, this same evolution has made SQL something of a dark art among programmers. It's good that the field is big and diverse and specialized! But also, there are tons of professional full-stack Web programmers who are functionally illiterate in SQL due to primarily using NoSQLs or ORMs.
Thanks for that, I'm used to ERB referring to Epic Rap Battles of History.
> Parses input fast enough to update on every keystroke, ensuring real-time responsiveness…
Wow!!! Cool to see ERB being embraced and enhanced in this way, I’ll have to check it out
If it is what I think it is, it’s extremely neat. Parsing both HTML and templating syntax at the same time is way more robust than doing just the templating and hoping for the best.
I was thinking about something like this, but with some blend of Jinja2 / Twig / Nunjucks [1] syntax and Svelte/JSX-like use of variables in element attributes:
{% for para in page.body %}
<p class={{ para.class }} {{ **para.attrs }}>
{{ para.text }}
</p>
{% endfor %}
[1]: the irony is not lost on me that I’m mentioning Python, PHP and JS template engines in a Ruby discussion :-) Liquid is the closest equivalent I think, but there was some crucial piece missing last time I had to use it, though I can’t remember what exactly.
This is something you could do with tree-sitter https://tree-sitter.github.io/tree-sitter/
I've been working with FastHTML and I have to say, I rather enjoy HTML-markup-as-objects.
It works pretty seamlessly and you get something like this:
@app.post('/part/add')
def create_part(part_number: str, name: str, description: str):
p = Part(part_number=part_number, name=name, description=description)
p.save()
return (p,
Input(placeholder="part number", id="part_number", hx_swap_oob='true'),
Input(placeholder="description", id="description", hx_swap_oob='true'),
Input(placeholder="name", id="name", hx_swap_oob='true'))
Phoenix (Elixir) has a very elegant version of that, without the need for the extra indent:
<p :for={para <- paras} class={para.class} {para.attrs}>
{para.text}
</p>
I was afraid at first this is the only option (which makes it difficult to generalize this to loops with body consisting of anything but a single element). But as an optional shorthand it is indeed pretty neat! (Personally though, I still like explicit “layering” of a separate `for` block a bit more.)
I'm not seeing any ERB here. Whatever blend you came up with could be done in ERB which just combines Ruby with HTML.
Template engines like liquid are good for simpler use cases where you'd want your end users to write templates (who aren't programmers)
Yeah, that’s intentional — I think having a clear separation between templates and code is a good thing. Regardless, you can use most of Python syntax in Jinja2 (and in my interpretation too, of course).
And no, it’s not only good for simple use cases. Template inheritnace alone is a killer feature for bigger projects: https://jinja.palletsprojects.com/en/stable/templates/#templ...
One thing that's not very clear from the documentation is what the application of this may be. I see that it parses ERB and or HTML into an AST. Is this intended to enable improved HTML and ERB linters and language servers? This seems like a tool that other development tools will benefit from.
I realize this is new, but as tools start using herb, it would nice to link to those tools from the herb website and or github readme.
Yes, I believe tooling, linters and language servers for HTML plus ERB is what Herb is for.
If you're not familiar with the Ruby ecosystem, the site does a very poor job of communicating what this is actually about. A single definition of ERB would have helped a lot.
I’m not sure it’s targeted towards those not familiar with Ruby... though yeah, at least mentioning it’s a templating engine would make it a lot easier to grasp.
(ERB is, I think, “embedded Ruby”, and it functions basically like old school PHP: you just insert pieces of Ruby code wrapped by <% .. %> or <%= .. %>: https://github.com/ruby/erb#recognized-tags)
ERB is also the default templating language of Rails. I wish Django would use an embedded Python instead of the mutilated tool it uses in its own templates. Not only it's yet another language to learn, but it's also underpowered and it forces developers to define custom tags and filters where a call to a method of a plain Python object would be enough. Apparently they are afraid that people embed logic in the templates but I've seen db calls inside the Python code of the custom tags. There is no perfect defense.
endfor, so it's not 100% real Python but I see that handling structure with indentation inside an HTML file could be a problem. Sometimes it's a problem even inside a Python file. I often have to undo and start again after moving code around. "Was that line inside the if or outside it?"
It's great to see new developer tooling advances in Ruby ecosystem! Looking forward to the VS Code integration as well as linter integrations.
I hope this results in a vastly improved version of the VSCode extension vscode-erb-beautify.
Now I am idling waiting if this will be picked up by Rails Team. Making it first choice default.
Excellent, I was looking for a Educational Records Bureau parser.
Oh, wait...
[dead]