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.

Belittling competitors is not a good competitive strategy, the community is smart and won't be fooled by it (https://news.ycombinator.com/item?id=32626873). If you want to promote something under my post, that's fine, people will make their choices. But if you're going to unjustly discredit JSON For You by ignoring the facts, I find that unwelcome and offensive. I suggest we compete by improving our products, rather than by smearing each other or engaging in price wars :)

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!

Thank you very much for sharing your thoughts! Based on feedback from multiple people, it's clear there's a significant issue with the product pricing, which I'll seriously reflect upon! From your perspective, there seem to be two issues:

1. The price is too high.

2. Dislike for subscription-based payments.

I have no problem with the first point, but I'm curious why everyone dislikes the subscription model so much? Or at the end of the day, is it really because the price is too high?

Oh, my bad. I'll change it.

Haha, that's a sharp critique, and I've also felt that the development of the web isn't fast enough. But actually, when you think about the web from ten years ago, or even twenty years ago, there has been significant progress.

I understand your point, but I believe that a one-time payment is not conducive to its ongoing development. Think about it, if you charge all the money at once, where does the motivation to continue updating come from after a year or two? But indeed, there is an issue with pricing. You mentioned the $5-$10 price range for a perpetual license, right? If it were a subscription model, how much would you be willing to pay per month?

Indeed, JSON For You is significantly behind visidata in handling table data compared to it. Their focuses are different, perhaps I can learn some highlights from its design. However, if you have needs for JSON processing, you might want to give JSON For You a try, haha.

I think the main reason is the rapid development of web technologies, which has significantly reduced the cost of developing software with a GUI. And web technologies are best suited for the web itself, whereas running locally would introduce additional development costs.

You mean offering it for free to everyone, but driving traffic to social media? Also, can I ask, from a consumer's perspective, what pricing do you think would be acceptable for my product?

Thank you all for your suggestions and feedback, really helpful to me. I am offering a coupon for the first year free (limited to 10 uses) as a thank you: UZNZQ5NW

I'm wondering, if I offer an embedding feature, would people still be as eager for a react component? For example, something similar to CodeSandbox's embedding capability.

Yes, it requires regular payment, from the SaaS perspective, since the cost is a monthly expense, adopting a subscription model is understandable. This pricing was inspired by https://jsoncrack.com/. May I ask, is there anything on the pricing page that is hard to understand?

Thank you very much for your feedback! It's very insightful. Are you saying that for local tools, people are more willing to purchase through a one-time buyout rather than a subscription model? Because they feel that a subscription doesn't provide continuous value and thus isn't worth the price?

I've done my best to optimize it, although there's still room for improvement, but it's quite challenging (but I'll give it a try). The reason is that we're constrained by the browser's UI thread being single-threaded, so almost all online JSON tools will lag or freeze when handling large amounts of data (e.g., over 1MB).

You can try my website, I guarantee you'll be satisfied, haha.

Yes, I've thought about it, but I haven't come up with a good implementation approach. Do you have any good ideas? Here's the problem I'm facing:

I want the table view to support not just regular array but also complex object structures (like nested structures). The latter results in an irregular structure of tables within tables, and I currently don't have a good approach to implement this using a virtual list.

I didn't know about it when I was making mine, otherwise, I would have definitely borrowed some ideas from it, haha. I have considered view-based editing functions, and I'm wondering if it's really necessary (if so, it will be supported), because now it's quite convenient to locate the editing position on the left from the right view using JSON pointers for quick editing. I'm thinking that providing editing functions in a professional editor might be more appropriate. And thank your for your suggestions.