pavish
Joined 8 years ago
Joined 8 years ago
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.
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.
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.
[1]: https://github.com/centerofci/mathesar [2]: https://github.com/centerofci/mathesar/discussions/55
Here's the issue that tracks it: https://github.com/centerofci/mathesar/issues/2634
Thanks!
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.
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].
[1] https://mathesar.org/roadmap.html [2] https://github.com/centerofci/mathesar/discussions/2266
We've documented the differences between Mathesar and other similar products including NocoDB on the FAQ section[1] in our website.
[1] https://mathesar.org/faq.html#how-is-mathesar-different-from...
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.
[1] https://github.com/centerofci/mathesar/discussions/113#discu... [2] https://mathesar.org/roadmap.html
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.
Here's the discussion: https://github.com/centerofci/mathesar/discussions/833
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.
[1] https://docs.mathesar.org/product/users/ [2] https://mathesar.org/roadmap.html
Github link: https://github.com/centerofci/mathesar
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.
The discussion thread on Github is here: https://github.com/centerofci/mathesar/discussions/55 and we can also discuss on HN. Thanks.
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.