piranha

Macbook Pro mic is literally much better than most webcams mics right now.

Look at my profile, lol.

Also, Ukrainian propaganda does not exist. It’s more of a for-hire services that work for whomever pays more, not for the state itself. It’s one of the reasons why shit like that happens, since there is no state-backed push against Russian agenda.

Because Russia actually prefers status quo! It’s a way for them to have a hand in actual country’s (in this case Moldova) inner politics. They are pushing “you’re not hearing us” agenda and are trying to convert the region to autonomous republic inside a parent country with a veto-like rights to have even more influence.

It’s a way to prevent parent country aligning with the Western world.

Also, it’s a known enormous money-laundering hole for Russia’s government schemas.

DNR is only there because of Russia. I have a lot of relatives in the region and visited many times. There is no other reason except for Russia pushing “different identity” topic for decades. First with propaganda and collaborationists (money), then (more recently) military. It’s not a people’s republic.

I don’t know about Kosovo, but I know for sure about DNR. Transnistria is a crappy corruptionist hole for money laundering, there is nothing about people’s will there as well.

It’s a Russia-backed puppet state, the same as Abkhazia (same period of time), South Ossetia (2008), or a newer DNR/LNR (2014). It’s not people that decided to do something, it’s that big pile of shit country making life worse for them.

Honestly, I now think that the main reason was different. I was fed up by my Macbook Pro's butterfly keyboard and started working on Macbook Air '15 again at the end of 2019. And in three months I was increasing annoyed by our site loading time.

And then it hit me. MBA is not the slowest laptop out there. It is much worse for a large part of our users.

This is where I started thinking we should jump off the hype ship. :-)

Well, the reason why I started writing my own library is because I couldn't get all functionality I needed from Intercooler. Why it does not depend on jQuery? Because I wanted no dependencies. :-)

And a "monster" is sarcasm referring to that React bundle I described before.

> why would it make an api call

Because this introduces clear separation of concerns? You don't need to make this API call via HTTP, you can just call a function. You don't even need to generate/parse JSON!

I know that because this is what we are doing. Just calling a function called "httpapp". :)

Batching is doable. I even understand how to do it in htmx. The problem is that

1) htmx started later than I did

2) inheritance is like a plague, and I'd really want it to not exist

I'll try to explain my stance. When you're a developer, you naturally drift to solutions which require you to write less or write faster. And inheritance certainly helps with that in simple cases. TwinSpark had inheritance up until we tried to implement sign-up/in logic.

Damned popups... Anyway, that's the day we've killed inheritance: https://github.com/kasta-ua/twinspark-js/commit/5714ceea9836...

And if you have two APIs - with and without inheritance - developers will use the first one by default. And when it bites you it'll be painful.

So if Carson reads my rant and decides to remove inheritance - I'll gladly move to htmx. If not - maintaining a library which is less than a thousand lines of code is not that big of a burden. :)

That is a good list. Have you heard about ClojureScript? Obviously, TypeScript is not supported, but everything else is.

> How long do you think it will take to incorporate them into your new tool which you just rolled from scratch?

Here is the news: we will never add them to the new tool. No TypeScript, no compilation, no routes, nothing.

> If I am your CTO

Good news you're not, right?

That is true, but the effect various "quirks" have on result are very very different.

I did not decide to switch from React with a light heart, it was a long and painful decision. But it seems to me that React's path of least resistance leads to a slow bundle, and you're going to fight an uphill battle.

LiveView is also very interesting. The main reason we went other way is that amount of connections and state held on server will be really high, plus we have some clients with bad connections and regular HTTP works much better on those than websockets.

This is why it took four months, we had to change all React-isms to something that works in both modes. One particular thing could load less HTML, and it'll require some attention to make it so - but as we're deprecating React version of catalogue, it'll be easier to do.

:-) yeah, in the heat of the moment. There is of course things we could do to improve bundle size, but it's all components and logic. We didn't do any css-in-js or any other fancy stuff.

> The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting.

Mostly because of initial data. Index page is still on react, so you can go on https://kasta.ua/ and look for element `#initial`.

> consider that the readers don't have the same background and context as you, and we all discuss based on those.

Okay, so how about not inventing outrageous ideas on the spot and just consider what is written?

It's equally as hard to unload what's been boiling in your brain for last half a year. I'm reading comments and trying to decide where to expand my post, of course, but this "binary" thing just got me laughing.

I tried to do that in the article. But the thing is that when you're writing a little piece of code React makes it dead easy to make hover in your code. There a lot of little things like that.

You start out with good intentions, but after 4 years of different people certain parts of codebase start looking really weird even with code review. You just can't catch every little detail.

And this is why tools should make it easier to do good thing (good as in what you'd want to see in the end).

> additionally, I highly doubt that the author has replicated this functionality by using his new turbolinky framework.

Which functionality?

> a bunch of UI requirements

So your point is that you don't really know, but let's blame them for trying, or what?

Oh yeah, binary assets. Yeah, it is certainly binary assets. We just embed node.js in there. /s

The thing is that your tools should be making good this easier than bad things. And React is the opposite of that.

Okay, maybe I should elaborate a bit on that. But React is better for developer experience like it is. But when you're talking about code splitting and service workers and other crap it's just a deepest rabbit hole out there. It's unmanageable.

It always had server side rendering. https://solovyov.net/blog/2017/server-side-rendering/

So you suggest that all libraries outside frameworks are incomplete and buggy? Can’t really agree with you!

I wouldn't use Clojure if fast startup time is important for you. So it's okay for servers, but not okay for (in general case) for command line tools. With GraalVM this is changed a bit, but then compilation of non-trivial projects with GraalVM is also non-trivial.

If you need a low memory consumption then Clojure is also not a great choice.

We've built an ecommerce site on Clojure though and it's been great. :)

Well, it’s the same size as intercooler plus jQuery, so not a lot of savings here. :)

Hey, I’m really interested what is wrong with Segment if you don’t mind (not affiliated with them). Email is in my profile.

Because he is not talking about side project! “Side”-ness in this case is his service not being a necessity for someone.

That is a weird claim to make and completely not true in my experience. Idiomatic Clojure is faster than any JS except maybe asm.js-like stuff.

I love Helvetica, but a bit bigger than default font size right now.