Glad to see Echarts getting the recognition it deserves. It is arguably the best open-source visualization library out there.
Here are some points others haven't mentioned:
(a) Uses canvas by default. Faster than any other library I've used.
(b) Extremely flexible. Want to write your own widget on top of the graphs (eg., a customized tooltip). Possible!
(c) Provides a lot of metadata. Want to get the position of a point in the rendered chart, to use in your code? Entirely possible!
(d) Works really well when importing into legacy web apps. They even provide an option to get a customized build on their site.
(e) Very good at handling streamed data. The animation is very smooth between data changes.
I've been using it for almost 7 years now for various production and personal projects, and it's still my go-to library. Their docs have come a long way since then.
They do have long standing bugs that get annoying, e.g, dealing with 0 when using log scales, provided there are workarounds for it. I haven't noticed any blocking bugs for most common usecases.
> Glad to see Echarts getting the recognition it deserves.
Why is it so rarely mentioned in chart libraries comparisons? Its not even listed on the Wikipedia page for JavaScript chart libraries. I discovered it by chance through Apache Superset.
I agree with most of what the author says, except the part about reactivity. I attribute that sentiment to the author being less familiar with Svelte.
I do think that people new to Svelte find it hard. It takes a while to understand how the `$` reactive statements work, and when and when-not to use it. When I first started working with Svelte, I tried to do things the React way and shared similar frustrations. Now that I've been working with Svelte for smaller and bigger projects for nearly 5 years (yes, since 2.0), I find Svelte's reactive pattern simple and intuitive.
There are some aspects I find frustrating with Svelte. One example is being able to pass templates around. With React I'd just pass JSX, but since Svelte is statically compiled, I've had to create components for such scenarios. Slots don't cover all usecases. I can live with this though.
I have built a couple large projects using Svelte and haven't faced issues with scaling. I found Svelte to be quite flexible, which has enabled me to build fast, and maintain a performant codebase.
My recent project is Mathesar, which has a large frontend codebase in Svelte + Typescript [1]. It's also open-source so you can check out the codebase. We use pretty much all of Svelte's features and we even implemented a full component library. Here's an old discussion for deciding which frontend library to use for Mathesar, where we selected Svelte [2].
We have had to establish a number of patterns (including around reactivity) so that new contributors don't break things, which happens more often than you think.
Svelte's primary issue is a lack of established patterns, which makes it easy for new Svelte developers to get things wrong. React has a number of such patterns due to it's massive community. I believe as Svelte's community keeps growing and more projects choosing Svelte, this would be tackled.
Here's more clarity on what I was attempting to say: I had to understand the internal working of the reactive statements inorder to use it the right way and it took me a building a couple smaller projects to completion to get there. I believe this was because at the time I built them, I did not have enough references and projects where similar problems were tackled.
After I understood how it worked, which was about 3 to 6 months into using Svelte v3, I found it rather simple and intuitive. I've been working with Svelte for nearly 5 years overall. It did not take me 5 years to find it intuitive.
We tested importing the files from the link and right on, some of the imported tables do not seem to work as expected. You've just helped us discover a bug.
A hosted version is definitely on our plans for Mathesar, and being able to share tables and explorations publicly via a permalink is part of our roadmap[1][2].
Apologies, somehow missed that. Thanks for the speedy response. Your explanation is very clear. Something that is keeping me tied to Airtable is their 'interface designer'. Allows for rapidly building internal admin tools. Something similar is apparently on NocoDB's roadmap (they are calling it page designer I believe). Am I correct in saying that this not something that is on your current Roadmap (had a look, but did not spot something similar, but could have misread)?
You're right, it's not in our current roadmap, which focuses mainly on features that improve data entry, analysis, visualization, and collaboration. Having said that, Mathesar could grow as a product and have a diverse set of features we've not yet planned, in the next few years.
A feature to build interfaces for internal admin tools sounds very cool, and while we cannot say that it's coming for sure, we'll definitely be discussing it. Please feel free to open a feature request issue on our Github repo, we'd appreciate it.
To add to what Pavish said: Our designer is excited about building an Airtable-like interface designer, but there's a lot of complexity involved, and it will cater to a whole different category of users. We want to get our current features to a more stable state before jumping into that. It's definitely on our radar, though.
Thank you! We're glad to take your feature request into consideration.
We have had discussions regarding auditing in Mathesar[1], though it's not explicitly documented in the roadmap yet. We do have plans to implement Undo & Redo support for data editing operations in our roadmap[2] which would depend on the auditing implementation.
We also intend to release our Svelte component-library as a separate package and considering if we should establish a GalaxyQuest theme when naming it, perhaps Laliari.
My previous job was in a biggish e-commerce company and the business teams would send spreadsheets with corrections to the data (like updating descriptions, changes in pricing etc.,) almost every day, and the developers had to make those changes in production.
We ended up building an inhouse application to let the product team edit production data directly, with some restrictions. One of Mathesar's goals is to solve collaboration issues like these.
Mathesar allows setting up users with different access levels[1], so it's easier to create users with limited access. As part of our roadmap[2], we also intend to allow configuring permissions at a more granular level, such as row & column level access to tables. So, developers could breathe freely when providing business teams access to the underlying database.
We are in the very early stages and are looking for opinions on choosing the frontend framework/library. It would be great if you could help us out on this.
> Well, it's because adults didn't want their children to become fat, you see.
This is a sOuNd argument. It stands to reason that as you mentioned, it is something you can totally teach your children without engaging them with books like Charlie and the Chocolate Factory, where the verses literally compare fat people to pigs and portray them as disgusting beings. Do you really think it teaches kids to eat less or to hate fat people?
> The reasonable response is something along the lines of "eating too much will make you big, and it's not good for you, but that doesn't mean you should be mean to that lady, or treat her differently from anyone else".
Some people, including my friends, are fat because of genetics and health disorders. Things that they cannot control. I've seen them eat very less compared to anybody else, practically starve and still remain fat. Eating too much is not the only reason.
The author never in any manner specifies eating too much is okay. All the author tries to say is that being fat doesn't make someone less of a human being. How exactly do you think you'll be able to teach your kids to not grow into being fatphobic when you portray being fat an undesirable quality, as you're trying to say here. Apart from themselves, doesn't this automatically burn the image into their heads that they should never love anyone who is fat?
I remember the exact kind of argument being used to tell kids that "you shouldn't treat queer people differently from anyone else, but you cannot be queer yourself".
> Imagine this. Let's say we come up with "Natural Dental Acceptance", "natdent" for short, a burgeoning movement for people who believe plaque is a protective coating for one's teeth and that "bad breath" is fake news that can be sufficiently combated by chewing Mentos. I could imagine now the blog post claiming children's literature is "netdentphobic" by claiming children need to brush their teeth etc, filling their heads with visions of "mouth bacteria" that nobody can even see. That's the level of ridiculous this post is.
This doesn't make a shred of sense. Nobody is preferring about random blog posts over science/good health here. Being fat and being healthly are two different things. Some bodies are just fat, and that doesn't make them unhealthy. All the author wants is for kids to be not bullied over their bodies and not form opinions on others or themselves just based on how they look. I can't even fathom how you went from there and arrived to this messed up logic.
> When kids become "fatphobic", we are arming them with important health information that can increase their lifespan and health, reproductive fitness, and more. If they follow through and live healthier lives, they will be happier people.
Wow. I regret posting this on hackernews. I genuinely believed smart people would be able to understand issues faced by other "undesirable" people in our society. By your argument, an unhealthy child should not exist/can never be happy. I am thin and I have a rocking bod and I have asthma, a condition that's going to exist as long as I live. Basically, you're trying to say that I can never be happy and I shouldn't exist.
Does this reply seem like I'm totally misunderstanding what you're trying to say? Yes, I was going for it, because that's what you've done with what the author is trying to say. Maybe you should first teach your kids to not grow up to be like you.
I don't care if this gets me blocked from here, while people advocating fatphobia, racism and denial of basic human rights, still get to say whatever they want on hackernews. This place isn't good for anything other than tech, especially not social issues. People here seem to have decent IQ and very little to zero EQ.
> Some people, including my friends, are fat because of genetics and health disorders. Things that they cannot control. I've seen them eat very less compared to anybody else, practically starve and still remain fat. Eating too much is not the only reason.
Sorry, but ultimately, I don't believe this. I do believe that people can be genetically predisposed to obesity, but the fact is, you cannot actually grow larger if you consume less calories than your body needs for maintenance. The laws of thermodynamics don't allow it.
What is actually probably happening is an unfortunate and frankly sad cycle of starving themselves and then binge eating when nobody else is around; it's an eating disorder, which is something treatments are evolving for, and something that can be prevented by heading off the problem before it starts. This begins with good food in proper quantities as a child, and it begins with learning self-control.
> By your argument, an unhealthy child should not exist/can never be happy.
You've run really far and wild with your interpretation of my response here. I really can't fathom how you got there from what I posted. All I am saying is that parents have a responsibility to instill a sense of personal responsibility for consumption in their children; and that this follows from understanding what life situations over-consumption leads to. I specifically said I educate my children to not treat fat people badly - but that doesn't mean I'm going to paper over it and pretend it's not a problem. I've also told them to treat smokers with respect and not jump on them and attack them for their habit; I see fatness much the same way. A regrettable thing that can be prevented with early intervention.
If a bit of fear is required for this to work, so be it; it's a great motivator for a childish mind, and works for many other things, like "don't jump in the pool or you might drown", "don't run off in the woods or you might get eaten by a bear", etc.
> I don't care if this gets me blocked from here
It shouldn't. We're just having a discussion. Disagreement is healthy. Chill out, I have plenty of EQ.
Part of that is understanding that healthy people have advantages in terms of their own psychological state by virtue of knowing that they are in a sound body and that they've done what they can to ensure their own fitness and liveliness. We can't just fix the psychological, physiological, short-and-long term health issues, and emotional downsides of being fat by having everyone pretend that "fat is beautiful". It isn't; it never will be; tens of thousands of years of evolution have pre-trained the neural networks in our brains to recognize reproductive fitness, and that is linked 1:1 with physical fitness in any reasonably evolved civilization.
Here are some points others haven't mentioned:
(a) Uses canvas by default. Faster than any other library I've used.
(b) Extremely flexible. Want to write your own widget on top of the graphs (eg., a customized tooltip). Possible!
(c) Provides a lot of metadata. Want to get the position of a point in the rendered chart, to use in your code? Entirely possible!
(d) Works really well when importing into legacy web apps. They even provide an option to get a customized build on their site.
(e) Very good at handling streamed data. The animation is very smooth between data changes.
I've been using it for almost 7 years now for various production and personal projects, and it's still my go-to library. Their docs have come a long way since then.
They do have long standing bugs that get annoying, e.g, dealing with 0 when using log scales, provided there are workarounds for it. I haven't noticed any blocking bugs for most common usecases.