Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

321–330 of 338 posts

Re: Comparing Svelte and React

#321

Earlier quoted context omitted.

The "magic" is very simple and understandable if you read the docs; I fairly quickly gained an understanding of it that allowed me to dig into the odd performance issue or bug without much trouble 1) Observables are properties on objects; when their getter is called, it becomes "tracked" (subscribed to) by the currently-running tracked function. When their setter is called, it publishes to all subscribers. This happe…

Great explanation! And keep fighting the good fight pushing MobX ;) Pretty much everyone I know who has tried it has ended up loving it, but it can be hard to convince people to give it a go (because of FUD around "mutability" or "magic" or whatever...).

By the way this conversation inspired me to make this: https://github.com/brundonsmith/crowdx

It's a heavily-commented, minimal reproduction of MobX's core functionality for the purpose of understanding

Re: Comparing Svelte and React

#322
post #12

Earlier quoted context omitted.

I use Svelte + TypeScript in my personal projects, what issues did you run into?

Last I checked it was impossible to parametrize component type. In React you can write ` users={...} />`.

I am not sure I understand. In the `MenuSelect` component you can declare `export let users: Array;` and then pass into `users` anything that has the `User` interface.

Re: Comparing Svelte and React

#323

Earlier quoted context omitted.

Great explanation! And keep fighting the good fight pushing MobX ;) Pretty much everyone I know who has tried it has ended up loving it, but it can be hard to convince people to give it a go (because of FUD around "mutability" or "magic" or whatever...).

By the way this conversation inspired me to make this: https://github.com/brundonsmith/crowdx It's a heavily-commented, minimal reproduction of MobX's core functionality for the purpose of understanding

Wow, nice work! I’ll take a proper look at this later today, thanks for sharing :)

Re: Comparing Svelte and React

#324

Earlier quoted context omitted.

Yes, and I remember precisely how many apps just encoded the DB credentials inside of the code - with no access/rights abstraction whatsoever. So basically godmode. Thats why we use service layers in Apps today (REST, SOAP etc.) instead of granting a user's process godmode access to the DB.

Why godmode? If your DB user is restricted to specific tables and columns, he is controlled. If you eventually get access to the data, does not matter how many layers are in-between (REST, SOAP). You still got the data, so that's a "god mode" in the same sense.

Row/Table level access controls don't work; you can't model use cases like "a user may not insert an order if he has 3 ore more unpaid invoices" or "a user can not insert anything until his password was changed in the last 30 days" etc. We have been there, it doesnt work. Thats why we use service layers of the DB to assert business logic.

Re: Comparing Svelte and React

#325
post #301

Earlier quoted context omitted.

Oddly, despite the immense resources that Facebook has available, Facebook in a browser is slow and glitchy, especially after the most recent redesign.

writing react apps in a proper way is hard, very hard. plenty of companies out there big and small can't do it. once you've a professional react dev, you easily recognize the react apps due to the subtle bugs. makes me miss my old team, where our big react app was actually performant.

If a framework/library is very hard to use correctly - even for people who are not only experts, but contributors - then that's a huge red flag against it.

Re: Comparing Svelte and React

#326

I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…

I'd agree on the architecture astronauts, but it would still be useful to see some good open source code bases using Svelte beyond the "todo list" level. For example:

- has a test suite

- integration with some backend framework (including secure auth)

- complex global state management requirements

- routing

Re: Comparing Svelte and React

#327
I work with Vue every day at my day job and I spent about 200 hours on the side building an online Svelte course. I really enjoyed the syntax and readability of .svelte files. Local dev environment was a great developer experience and the lack of boiler plate was nice coming from a Vue background.

I built an SPA with an Express backend and my biggest complaint was the lack of an official front end router. The community based router libraries had lots of issues and quirks and I didn’t want to lock into using Sapper at the time. Svelte itself was rock solid though and I look forward to trying Sveltekit (think Next.js for Svelte) in the future.

Anyway, here comes the shameless self promotion:

https://www.newline.co/courses/fullstack-svelte

Re: Comparing Svelte and React

#328
Svelte has made the classic mistake of creating a template-based framework, which inevitable leads to a DSL, then to a miniature programming language, then to a nightmare of incidental complexity. React won for a lot of reasons, but near the top of the list is JSX.

JSX is not a templating language, it’s just syntactic sugar for plain JavaScript. I never have to wonder what new features have been added to JSX, I never have to struggle with extensions to JSX that some 3rd-party library depends upon. Template-based frameworks are akin to Lisp reader macros, and this is especially true for Svelte in that it is a compiler. But reader macros will kill a language’s ecosystem quickly, in that they break composability. JSX was a clear winner over Angular’s directives for exactly this reason.

Svelte has some cool ideas, but regressing back to another Handlebars or Mustache isn’t one of them.

Re: Comparing Svelte and React

#329
post #151

Earlier quoted context omitted.

But I wish new frameworks stayed away from inventing new language syntax. Not only is it a cognitive burden on programmers, it throws all the tooling off. From Svelte: {#each cats as { id, name }, i} JavaScript already has facility for loops and mapping, and relying on that will automatically get you tooling/IDE support. React handles this aspect quite well, and to me that's a point in favor of React. I do agree with…

I was with you on this topic, and I have rants about this elsewhere. But with Svelte 3 I actually agree with their choice now: 1. The extra templating syntax is rather small and concise. And explicit. - There are very few directives, and they follow the same rules: `{# start block }{: alternative branch}{/end block}` - external data that comes from Javascript is always `{data}` - properties of html components that ca…

As I noted in another comment, what we’re really dealing with in compiled templates are reader macros. And unfortunately, reader macros break composability.

Re: Comparing Svelte and React

#330

I wrote my first decent size Svelte app (with a Rails API app backend) last year: https://www.listenaddict.com/ Of course, what you see is just a tip of the iceberg, having implemented a nice admin and moderator dashboard, keyboard shortcuts, animations, 12 different color themes (in light and dark mode), and more. Svelte just made it all so easy to do. Having done a good bit of React and Angular professionally, and…

Your site is brilliant and works really well. I’m also going to check out your YouTube channel.

Seconded. I am a back end developer and had a lot of fun watching your Svelte Sapper series; thanks for your work!

Quick question: which color scheme are you using in VSCode? It looks a lot like jellybeans for vim, which I love.

Post reply on HN