toinbis

Congrats on launch. Impressive demo. Keep shipping!

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!

Am very curious about the same very question.

"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 .

I'm one of them. Really proud!

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.

Love the fact that Release notes (https://www.sqlalchemy.org/blog/2023/01/26/sqlalchemy-2.0.0-...) give decent credits to SQLModel (https://sqlmodel.tiangolo.com/) for some of the typing innovations.

I use both mypy and pyright. Pre-commit hook/vscode runs checks for mypy, pyright, as well as pylint, flake8, black, bandit.

Why both? I just have more confidence in getting feedback from both of the tools.

I guess it's important to note that in many cases you'll be willing to pair htmx with either alpine.js (using https://htmx.org/extensions/alpine-morph/), or with hyperscript (https://hyperscript.org/, developed by same team as htmx).

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!

No, they are not gone at all.

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.

Thanks for great comment! I have one question.

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?

Thanks

Am wondering what react community thinks of DDD.

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.

Many thanks for any ideas and comments!

Haha - wonderful, good plan, fingers croseed! :)

Wonderful idea, great implementation!

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:)

Congrats again on shipping great product!

Edit: typos.

I do hope that python SDK, as discussed in https://github.com/temporalio/proposals/issues/20, is the next one in the list! :)

Sad to see a very concise comment revealing arguably the deepest and biggest problem of the frontend world - frontend architectures naming problem - being downvoted.

Things (https://culturedcode.com/things/). Google spreadsheet.

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.

Earlier(2020-09) HN submission with discussion on same project: https://news.ycombinator.com/item?id=24517925.

For those looking of component showcase i'd kindly advise to also look at https://bit.dev, https://github.com/teambit/bit . It is a standalone service that hosts your components, providing each of it as a npm package.

You end up developing the components in a separate repo, and in your main app repo you install each component as dedicated npm package. Those who get excited by `separation of concerns` pattern should find this a real joy.

Congrats on launch! Super cool product and I feel like trying it out in the SaaS i'm building. Few initial questions:

`Our multiplayer WebSocket servers live on the edge` -> from your Jobs page I realised that you use AWS. Does that mean that it's AWS cloud that you're using? Have you considered using Cloudflare Durable Objects(DO) for infrastructure - what are the thoughts for DO suitability for your use case (besides it currently being in beta phase)?

Congrats once again on shipping something world needed badly!

Upd: removed the question which was a bit illogical :)

Would love to test it out! Have been evaluating Chamber (https://github.com/segmentio/chamber) to solve same/similar problem. But Leapp has UI(cool looking!), so it's an obvious advantage.

Would be keen to hear what other differences Leapp developers would name in comparison to Chamber. Thanks!

Well done, thanks for sharing!

> This doesn't make any logical sense. I was clearly referring to Facebook primarily as an implementation, not as a brand.

Facebook is a product of 100000 different implementations which might theoretically change daily. If we were discussing can we do thing X or Y with MySQL, and you'd say 'look - there is facebook, it's working, it means you can('t) do thing X or Y with MySQL' - that would not not be very specific. I'll add term 'architecture' to discussion.

> OK, so Netflix, Facebook, Instagram, AirBnB - all web app implementations - cannot decently A/B test, but you can. Gotcha.

So, let's talk architectures. "Netflix, Facebook, Instagram, AirBnB" - if you can, please specify what architecture and for what purpuse they have implemented. And tell about the specific example. We will have something to discuss, now we just don't.

For instance, https://docs.developers.optimizely.com/full-stack/docs/optim... -> this is architecture of optimizely experiment for React. This is other feature https://www.youtube.com/watch?v=NRLhlTopFzw being showcased, but you can get a sense of how the SDK is being used. Let's say bussiness requirement is to run experiment where for 50% of traffic you show nothing at the top of the page, for other 50% you show country flag image and city flag(cout of arms) image. Site is built with next.js. The next day you throw next.js out and build your site from scratch on other page. How would you implement that?

>How would you know, anyway?

a) You use common technical sense and realize that's the only way it can be;

b) If you don't trust your guts, you go and analyze performance tests: https://css-tricks.com/radeventlistener-a-tale-of-client-sid... and learn that react is 40x slower that the industry standard. Not stressing 40x, just - it's slower, was and will always be (except RenderToStaticMarkup and Server Side Components).

c) You go and check what world is using - https://w3techs.com/technologies/comparison/js-jquery,js-rea... , you realize that, statistically speaking, no one is actually using react, probably for a reason. (Ok ok, this argument is also a bit overstrech, and yet... :)

d) You can only know for sure by building stuff and comparing. You build https://turboeshop.com/fastestpageintheworld/ and https://gatsbyeshop.com and compare: https://imagebin.ca/v/5lrH1VnQBac7 .

> 'faster than many SSR industry peers or competitors'

'Not worse then most competitors' is not how you win in bussiness competition, is it? :)

> You further resort to a personal attack

Honest apologies if that sounded that way. If I may - I take all that back.

> I've got nothing against SSR, it's got its use cases and I've personally used it too, but you on the other hand seem to be an SSR jihadist

Ok, now we talk. For the record - I write a lot of client-facing vue code, sometimes a bit of react. Love both, great developer experience, I call them both 'godsend' for frontend development.

Yes, I do turn radical when people start shouting 'react is the answer, what was the question'. And this tread we are having discussion in began with 'you should do everything in JS/TS' statement. And believe me, there are many devs like this.

When faced such statements and situations I do take a stance and say that there are so many bussiness requirements that make hydration/js-navigation/react-vue-svelte obsolete from day one, they are just out of consideration when picking a stack.

Problem is devs makes usually make choices and bussiness usually does not not the costs they are incurring in letting devs to use tech stack they do love. Reactgasm(term found online) has it's high costs for some bussinesses. It sure does. It has obvious gains as well. Which are the greater - devs only can never decide, yet it happens that they think they can.

My main profession, broadly speaking, is e-commerce marketing. And when dev comes and says 'i'll use react in the acquisition funnel of the project you'll be optimising' - sometimes turning to SSR jihadism is the only way of winning an argument. Am glad we finally came to a conclusion that 'it depends on bussiness requirements', which I honestly think is always a start and end of discussions as such.

My final point is "react&friends are not default options for tech stack for ecommerce bussiness acquisition funnel (I have quite some expertese and many years of experience in this specific domain, that's why I allow myself strong statements), but in practice it may surely be a comlete opposite if bussiness decides so". That says nothing about that react or vue ar not great projects they do not have their use cases. In a neutral environment without react-jihadism i'm perfectly fine saying 'tech stack needs to meet bussines requirements', but that's only with an asterisk *if bussiness requirements are actually being taken into consideration, not devs just picking what they love and pretending everything else does not actually matter.

Many thanks for good discussion, apologies again if any of the statements were impolite, am not a native English speaker. Feel free to challange my technical discussions above, but I think I'll resist of pushing this further, as I've elaborated my point of view and then I believe it's about sharing ideas not winning arguments why we are in HackNews :) Kindest regards and happy holidays!

Hey, thanks for comment and sharing the React Server Components news - have checked https://reactjs.org/blog/2020/12/21/data-fetching-with-react... . 18:02 - "server components can not have any interactivity". So essentially this is (something similar to) renderToStaticMarkup with some bells&whistles.

Would live to share quote from https://news.ycombinator.com/item?id=25358976: "I feel like we're in a transition period where we will eventually get both the nice developer experience and flexibility combined with nice performance".

Am wondering if anyone tried to bundle vanilla js for dom manipulations alongside server-rendered react componenents which deliver html+css server-side. Where do you put js code inside the component folder? What are the patterns and best practices of using react only for html+css composition and using vanilla js for interaction? Thanks a lot for any tips!

https://github.com/fabiospampinato/cash of you want to build website, vue.js if you want to build an app. In app world, vue.js (options api specifically, which is easier to understand for newcomers) can get up and running faster than react. After you master app development, it comes down to ecosystem/tooling (pros and cons here with both react and vue) and mostly - personal preference.

Reply to a) No, it is not false at all. Let's skip the brands out of discussion. Client side a-b testing is impossible to be decent. Period. The fact that optimizely built something for react is not a valid argument.

Reply to c) Your react app is 30% slower that anything decent. Why would any bussiness owner would ever sign this off to happen in their acquisition funnel(i.e. where user experience is especially crucial)?

Reply to d) Decent is ~100% correctness and completeness versus ~70%.

Reply to "I guess you think it's just the exception that confirms the rule?" -> You keep mentioning companies and brands instead of implementations which suggest you have no experience on the implementation part. That is the thing - facebook does a/b testing server-side. And i'll just mention that facebook also used react to create their, arguably, second most important project - facebook ads manager. And it's a complete 'bollocks'(using your words) architectural decision to build such tool for react - it's a UX as terrible as it can get and i've used it for 5 years and I know at least 100 advertising agency employees who would sign this statement with their sweat and they are one of two. Just to give a counter-argument of the same origin as Yours one.

So am very thankful for constructive discussion - all your arguments are fair and well elaborated. Just you can't buy any of them. Really hope am not insulting with my strong opinions, always happy to discuss further!

Rephrasing https://www.swyx.io/svelte-sites-react-apps/ :

a) react/svelte/next/nuxt/gatsby/sapper/angular for apps;

b) django/rails/express.js for sites;

As for pageload, next.js is 30% slower than vanilla website. No ecommerce bussiness should ever alow this(my personal opinion).

Take a look at my top comment of https://news.ycombinator.com/item?id=25342767 for more details.