require "kogui"
class App
include Kogui::Component
def render
html lang: "en" do
[
head do
title { "Title" }
end,
body style: "width: 100vw" do
[
h1 id: "__title", class: "bold__text" do
h1 style: {"font-size": "2rem"} do
Array.new(5) do
h1 { Time.utc.to_s }
end
end
end,
]
end,
]
end
end
end
app = App.new
html = app.to_s # <html><head><titl...
May i suggest using blocks/named_arguments instead of arrays/methods? I think that would make the API a bit cleaner.
E.x.
class App
include Kogui::Component
def render
html do
head do
title "Title"
end
body styles: {width: 100vw"} do
h1 "Hello world!", id: "__title", classes: "bold-text", styles: {"font-size": "23px"}
end
end
end
end
EDIT: To be clear html, head etc would still be methods, they would just use a block to know what goes inside of it, versus an array of items.
We’re planning to release a shard with just the HTML part taken out so other libs can use it. Maybe you’d be interested in using that or working together on making sure it fits your needs?
@IEatReturnValues First off welcome to Crystal! Seems like you are new here so thanks for giving it a try!
I can understand what you mean, but I think the comment could be given more constructively. Not everyone prefers the same syntax, and it looks like he updated it to look a bit more Crystaly so maybe you like it now!
def render
html lang: "en" do
[
head do
title { "Title" }
end,
body style: "width: 100vw" do
[
h1 id: "__title", class: "bold__text" do
h1 style: {"font-size": "2rem"} do
Array.new(5) do
h1 { Time.utc.to_s }
end
end
end,
]
end,
]
end
I’d rather write normal HTML at this point… Templating degrades front-end development and makes web development far more convoluted than it needs to be.
It literally transformed a simple body tag, with h1 children into something that gives flashbacks of callback hell, but with ends
This is the total opposite of “elegant” syntax. Which is one of the beauties of Crystal.
@IEatReturnValues You are stating your opinion as fact. Some people like different things. It is fun to experiment too! See if you can comment a bit more positively and constructively. If someone sent your comment to your code how would you feel?
Second, there are advantages to approaches like this. You always have a correct end tag, you get auto formatting for free with crystal tool format. You can extract private methods to help make your templates more readable. You have access to all of Crystal so you can do some powerful stuff.
So before you judge something purely at the surface level, consider that there are downsides and upsides to every approach. This may not work for you, but it may work for others
Eh, I’d say objectively, a regular body and H1 children in plain HTML are easier to write, and much cleaner than template code. Far less confusing as well.
But I mean, look where web development is nowadays. Just layer after layer of stuff being added on top of it.
I agree to that. The concept of building HTML with a different language doesn’t appeal to me at all. I understand it can have some benefits, but essentially it’s just that you need the combined knowledge of two languages (HTML and Crystal) plus the builder API in order to work with that.
When you just write HTML with a simple template syntax, you’ll still need to learn HTML and the template syntax. But you don’t need to know Crystal to edit the HTML code.
Advertise: In case someone’s looking for a runtime template engine (works with HTML and whetever markup you like), take a look at crinja =)
@IEatReturnValues there is no way that is objectively true. I’d say Lucky HTML is much easier to write in almost every way. Fewer characters in many cases, auto formatting with Crystal, automatic end tags in the right places, etc. But that is also “subjective” not everyone is the same. Some people just don’t like it, that’s fine. But it is NOT objective
For example:
body do
h1 "This is my page"
div do
ul do
li "my item", class: "list-item"
end
end
h2 "some other headeing"
end
And in HTML
<body>
<h1>This is my page"</h1>
<div>
<ul>
<li class="list-item">my item</li>
</ul>
</div>
<h2>some other heading</h2>
</body>
As you can see the structure is identical that was a main goal of Lucky. If you know HTML, you pretty much know Lucky HTML. Plus we have a converter so you can copy HTML from the web and get Crystal out of it.
There are also lots of other advantages to this approach, like creating classes where you can have helper methods to extract HTML, makes it super easy to test because you can pass in methods just like any other class, and type-safety. In Lucky we disallow accidentally printing nil or some other object to your code. As I said, there are definite advantages, so…
…let’s stop with the “objectively better/worse/whatever”. It is simply false in both directions. Let’s be pleasant to each other and not arrogant. We have more in common than we think
Woow 10 years! Impressive! I have 12 years so does that mean my opinion matters more??
I agree front end dev has gotten complex, but the community does not need this kind of negativity. Please communicate more kindly and realize that not everyone has the same opinions or problems to solve as you. There is room for multiple solutions
There’s no integration currently. It could probably be made to work. But the interface Kilt offers is for compile time templates. So I’m not exactly sure how useful it would be for Crinja. It would probably lose a lot of versatility.
I wish you were actually asking and not trying to “catch me”, but it is incredibly simple.
You add event listeners in JS so that has nothing to do with this. If you are talking about Vue style attributes, then you do that like this: div "@click": "myMethod"
You are not contributing anything of value. Please stop commenting until you are ready to treat people like human beings that just might be as smart as you think you are
