Well done team Lithuania! Remember hearing Pixelmator founders giving a speech ~12 years ago. They were very vocal and repeated this many times: "Our marketing strategy is to just focus on the product". Not sure I agree with that statement, but they sure seem to followed it thoroughly. Congrats on the acquisition!
"I guess you could still have multiple Hono-based packages that handle segments of your backend" -> I am thinking the same - if you hit bundle size problems, you can just split your app.
I'd also love to see some benchmarks how bigger bundle size impacts the performance - i.e. 1 MB adds additional 1ms on average, or so... My platform of interest is mostly Cloudflare Workers.
It's surelly not "just another htmx framework" for at least one more reason - it has 100+ CEOs, way more than any other! Check them all out https://htmx.ceo .
Indeed it's hard to grasp what mission the framework is up to.
I'll just say though that am very happy to see htmx getting more traction.
I'm a technical marketer and I was really saddened to see trend of bussiness logic being expresses in TS and spitted out into small bundles for marketers to have no clue on what's going on.
Now I just say this magic combo to frontend team: htmx+alpine+xstate-fsm. And suddenly I have gained the control back! JS-in-markup is a dream comming true for those who actually keep working on optimizing the websites after developers create them.
Things that don't require request to server - managed by alpine, things that do require - by htmx. There are situations where both tools can be used, one has to pick.
Happy longtime Influxdb user here. I wanted to congratulate Paul and the team on reaching this milestone. Followed IOx development a bit - can't wait to finally test it out!
http://epydoc.sourceforge.net/api/ - epydoc has great combination of reference documentation combined with codebase visualization. Please note that the two visualisations in "Package epydoc" and "Package Organization" ar both clickable. Once clicked, also feel free to find and click "call graph", which itself visualizes, well, call graph.
Sadly epydoc is no longer maintened and only supports py2. Had an idea of porting it to py3, but never found enough time to do so.
The biggest thing I miss in react ecosystem is decent redux ORM. https://vuex-orm.org is just so great for so many use cases (agree that it might an antipattern in many situations). Is there any chance that https://github.com/redux-orm/redux-orm, which was actually what inspired vuex-orm, would get more love from anyone to become an actively maintained library?
I've been reading "blue" DDD book (by Eric Evans) and "red" book (by Vaugh Vernon) and that was a completely "my whole life was a lie" type of experience and relief at the same time. It's just so great to have the principles of who to structure the code. It, by definition makes, your codebase structure meaningful. Because it's structured according to some common knowledge, not your random thoughts at the time you were writing code.
I was surprised to find so little DDD react sample codebases. Let's say for backend there is huge amount of samples, i.e. https://github.com/kgrzybek/modular-monolith-with-ddd . For react/frontend I have bookmarked only https://github.com/talyssonoc/react-redux-ddd/tree/master/sr... and few more, but those others does not meet the optional criteria i like really much - at the highest (or at app) level all codebase need to have folders app, domain, infra and ui. Simple rule, but simplifies life a lot.
So my question is - is DDD for some reasons not very applicable for app frontend development. Or it just never became popular. Or maybe DDD is popular amongst react developers, just I am not aware of this.
Would love to see you guys partnering with TailwindUI somehow. That's my default go-to ui widgets library (it's not open source, so it might be challenging to find a proper partnership model with them).
Just bought a lifetime subscription. And as I already do have subscription - my last recommendation is to switch to monthly subscription model as soon as you can. Monthly subscriptions is just so much more profitable pricing model:)
Sad to see a very concise comment revealing arguably the deepest and biggest problem of the frontend world - frontend architectures naming problem - being downvoted.
Swithing between the two periodically every month. I think you just get tired of looking in many tasks in the same interface, that's when I do the switch :)
In performance marketing(=KPIS are a)sales volume and b) Cost per action - CPA) it's very simple - you can't scam how much you've spent on ads. Also you can't scam how much you charged the traffic you've bought. Both figures are reported by your finance department with pretty much 100% precision.
Yes, you do have a challanging problem of attribution. But the spend and revenue figures are what matters at the end of the day. And neither of them has any area for scamming (let's ignore edge cases).
Disclosure: only skimmed through the article and my arguments above are just directed towards the headline. However credible and opinion leader the author - Rand Fishkin - is, the article itself at the first glance did not inspired me personally as a worthy my attentive reading time.