bilus

Exactly! Which is why using AI to do spikes and then writing the code anyway is a fitting revenge. :)

BTW. This, actually, is the first comment I got; this blog is brand new. Thank you.

I'm hoping to get some early feedback for the API: https://github.com/bilus/live-templ/releases/latest/download...

I've braced myself for ANY feedback you can send my way, so go ahead. :) I don't work to work on this in isolation.

I'm personally quite comfortable with the API so far, the only real doubts is error handling, i.e. IncTemperature from the PDF can optionally return an error and if that happens, it kills the session (state for an open browser tab) and restarts it with no state. Because errors need to be handled as regular state in LiveView. But it may be counterintuitive for Go developers. If anyone is interested, I can go into more details on this one.

Couldn't agree more!

Thanks, good read. :)

Thank you.

It this case, this is more like a foster parent; Oya started as a part-time open source project, then Tooploox sponsored further development after having used it internally.

It was created as an independent open source project, then used internally @ Tooploox, then development got sponsored by Tooploox so it does make sense from our (very subjective) pov.

But I agree AFTER it got moved to Tooploox Github it looks kinda self-serving.

I think this is the key question we should address right there on the home page. Thank you for this.

It's language-agnostic. But point taken, thank you!

Thanks, I appreciate the honest feedback! We'll try better.

No. But it's a very valuable question; it shows we clearly have a problem with making it clear.

Not everybody uses JavaScript. There are many language-specific task runners (e.g. Rake, Mage etc.). Oya is aiming to be language agnostic and lightweight (not require a ton of dependencies).

This is a very good point.

Fantastic suggestions! Thank you so much for taking the time! We'll definitely going to take them into account and revise the home page. Good stuff!

You're not being negative, that's super useful feedback. We're using Oya internally but are still struggling with making it 100% (or even 80%:) clear what it is that it does. :)

Great point, thanks!

Scaffolding is just a part of what Oya. The purpose is not just creating new projects but also making managing them easier with focus on devops.

You can: 1. Create bash-based tasks similar to what Makefiles do.

2. You can parametrize these tasks AND templates using YAML files such as values.oya (they can be encrypted).

3. You can share/reuse your scripts by just pushing them to Github and tagging using a version and then import them into your Oyafile (`oya import github.com/bilus/mypack`)

Thank you!

Oh, I wasn't aware of that. Thanks for pointing that out and fixing the problem.

Thanks! I also hate flashy popups and stuff like that when I'm browsing a website. I hope that giving users a way to quickly send feedback while they're on a page will not only help owners improve the website but also create a sense of participation for visitors. Maybe not on the level of Wikipedia but in a small way you can also contribute.

Thanks, pushing the change right away.

The main idea is to make it as simple as possible. So no surveys (at least at this point) etc. As a visitor, just type in a comment, maybe highlight a part of the website and submit it. As the webmaster, you see feedbacks received from users.

lol ;)

Thanks for the feedback! Good point about the form -- I'm on it right away.

Good point, thanks! I went too far when trying to shorten everything as much as possible.

Thanks for the suggestion!

This is a fantastic point -- thank you. It's just it's not ready yet. I'm working on making it compatible with IE. Once it's usable, I'll definitely use it on the website.

You may be mistaking patterns with 'clever hacks'. If the 5-liner is about writing the shortest possible code, then it certainly isn't beneficial to anyone (except for the original author who has all the fun of coming up with a 'clever' solution). But useful abstractions are a different matter whatsoever.

Just look at Go channels or at reactive programming patterns. If applied to the right problem (i.e. a problem they help solve), they allow you to solve the very problem in a very concise and expressive way.

Having such patterns as a part of the language just makes them more popular and reusable.

And as far as your point, don't you think it's easier to spot a 5-line pattern than a pattern that is spread out over several classes and 200 or so lines of code? It all boils down to this: being able to see patterns or abstractions if you know that and having a common language across the team. Functional 'patterns' are just (arguably) more succinct than object-oriented ones (and it comes from someone who has been programming in C++ and Ruby for nearly 20 years).

Thank you!

Me too BTW. ;)

Really good ideas, we do have a few more and will be implementing them starting sometime soon but our focus is anyway more on increasing the retention and the referral rate at this stage.

Experiments with revenue are very important too though.

What do you think? Should we do revenue right away or retention/viral aspects first? I sometimes have doubts about this.