loggerhead

Sorry, my previous response misunderstood your meaning. JSON For You does draw inspiration from JSON Crack for its landing page, thank you for designing such a minimalist homepage and I will put JSON CRACK to my acknowledgment. In terms of functionality, the two products actually have significant differences:

1. JSON Crack focuses more on visualization, whereas JSON For You aims to be a all-in-one JSON toolkit. This is why you'll find many buttons on JSON For You's page, leading to decreased readability and increased user learning curve (though I've tried my best to optimize this).

2. JSON Crack supports visualization for multiple data types including TOML and YAML, but JSON For You does not support this, nor does it plan to.

3. I've noticed JSON Crack offers AI functionalities to manipulate JSON data, but JSON For You will not pursue such features. Instead, it provides this through local tools like jq.

4. When it comes to comparison features, JSON Crack seems to provide graph-based comparison, which JSON For You does not do (nor is it its goal). Additionally, JSON For You offers text comparison, which JSON Crack does not.

Maybe I should provide a comparison table on the homepage to help everyone better understand the differences between the two products :)

Good idea. I've received a lot of feedback from the community with people hoping for some AI integration features. I am seriously considering this. Also, in terms of product positioning, if I do offer cloud storage, I don't intend to view JSON For You simply as a place to store files, but rather as a remote configuration management solution. Thank you once again, you're truly a deep thinker.

Thanks, I will change it, it's really annoying.

Thanks, I will change it.

I have researched react-virtual, react-window, and canvas, and after long consideration, I ended up with the current solution. I might reconsider trying canvas again. Anyway, thanks.

A great tool that fills the gap of lacking a preview feature in the terminal with jq. However, for data processing, I think jq's DSL is more concise and user-friendly.

Thank you for your patient explanation! A very valuable perspective —- people are not willing to continuously pay for something static that doesn't get updated. Actually, I have plans to develop some features that require a server, but as you mentioned, perhaps I should put the blueprint in the README or on the homepage to make users feel it's worth continuously paying for.

Can I conduct a small survey? I previously considered offering a feature to store users' JSON in the cloud, but I didn't see the need since there's GitHub Gist, and you can always use that, so I didn't implement it. From your perspective, would you need such a feature?

Thanks. The main issue is that we can't reuse existing components, so the development workload will be quite large, but I'll think about it.

I strongly agree with your view. I used to be a loyal user of Sublime Text, it performed exceptionally well and was incredibly fast, which I loved. However, perhaps I misspoke, what I meant to say is that due to the low development costs and rich ecosystem of web technologies, current applications are more inclined to use web technology stacks when developing GUIs. But (yes, there's always a "but"), the performance of web applications is still far behind that of native applications (although there has been significant improvement).

Thank you for your support! I'm open to all kinds of feedback and want to understand different perspectives. After gathering enough input, I'll digest and understand it before making any decisions, ensuring not to take any single opinion as the whole truth.

nice work!

The issue isn't with the editor itself, but rather because rendering becomes very time-consuming when there are too many DOM nodes. This is due to the specification limiting to only one main UI thread.

Interesting perspective. Let me share my thoughts, which might relate to consumer psychology:

- With a buyout system, users perceive that they own the item after payment.

- With a subscription system, users perceive that they are renting the item after payment.

When there's a mismatch in expectations (I pay to own, but you only let me rent), users feel deceived and angry. The same issue occurs with the ownership of accounts in online games, where some game companies state in their terms of service that the game account belongs to them, not the user, naturally leading to user outrage.

Thank you for your support! I have indeed put a lot of thought into it, and it's something I use often myself. The crashing with large data volumes is a known issue that many have feedbacked on. I have plans to optimize it, but I'm not overflowing with good ideas. If anyone could offer some suggestions, I would be immensely grateful!