Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

331–338 of 338 posts

Re: Comparing Svelte and React

#331
post #55

Earlier quoted context omitted.

That should work in the provided example, but in general `fn(cb)` is different: you lose the implied `this` binding unless you do `cb.bind(something)` beforehand. There's also some unexpected trouble due to potential extra parameters. Consider the output of ['1', '2', '3'].map(parseInt) gives: [1, NaN, NaN] So yea, fn(() => cb()) is the same as fn(() => {return cb()}) – just syntactic sugar when the anonymous functio…

I consider myself a pretty advanced JS developer, and I still don't understand how "this" works in JS. I avoid using it whenever I can.

Yea, you can avoid it without losing much at all.

Most common place IME you end up needing to use it are when assigning functions on a class as event listeners: if you want to be able to remove them, you need to use the same value in `addEventListener` as `removeEventListener`; and if the function uses other properties of the class, you must use `.bind(this)` to correctly set `this`.

It may help to think of it like this. This code

  object.someFunction(a, b);
is syntactic sugar for

  someFunction.call(object, a, b)
So with most usages of functions, the `this` is implicitly defined. The trouble comes when you start passing around references to functions.

  const fn = object.someFunction;
  fn(a, b); // throw `this is undefined` error if function accesses this
Here, `this` was never defined. So you need to do one of:

  const fn = object.someFunction.bind(object);
  fn(a ,b);
  // OR
  fn.call(object, a, b);
The last thing you need to know is the difference between arrow functions and classic functions. Arrow functions _never_ have a `this` binding of its own. It doesn't make a scope. If the scope it was defined in happened to already define `this`, it would use that. Classic functions (`function blah() {}` or `const fn = function() {}`) do make a new scope, so they have a `this` binding, so if you wanted to access `this` of the outer scope you'd have to assign it to another variable beforehand

  class A {
    a = 1;
    fn() {
      const thisRef = this;
      return function () { return thisRef.a }
    }
  }
With arrow functions, it's easier:

  class A {
    a = 1;
    fn() {
      return () => { return this.a }
    }
  }

I think this is all you'd ever need to know.

Re: Comparing Svelte and React

#332
post #330

Earlier quoted context omitted.

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.

Thanks!

I think I'm just using the default dark color theme. (dark+)

Re: Comparing Svelte and React

#333

Earlier quoted context omitted.

> compiles to who knows what You can easily read the compiled Svelte output and see how each piece of template is wired to the state. There is very little cruft in it, and no real runtime library to speak of. The debugging experience (not that I have needed it much) is light years ahead compared to going through React's internals.

Yeah, but it's still a DSL and that means that I can't be sure that everything I can normally do in JS is valid there, and external tooling won't be able to make sense of it without additional work.

Those sounds like very abstract concerns - I haven't had any issues on those lines using Svelte for years now. The $: syntax is actually valid JS (labels) so standard JS tooling should always be able to parse it.

Re: Comparing Svelte and React

#334
post #251

Earlier quoted context omitted.

You don't pass by reference in JS. You pass references by value. Passing by reference has a well defined meaning in computer language terminology. It means passing something that references the variable outside the function. Something you can't do in JavaScript void someFunc(ref int v) { v = 456; } var foo = 123; someFunc(foo); write(foo); // output 456 Above we are not passing 123 (the value of foo) into someFumc, w…

I would argue that Javascript is a hybrid of pass by reference because of the case below though. function someFunc(v) { v.myvar = 456; v = someOtherObject; } var foo = someObject; foo.myvar = 123; someFunc(foo); // foo still refers to someObject // foo.myvar is 456 Banning our team from passing objects around except in specific, discussed, cases got rid of lots of difficult to track down bugs.

You'd be wrong. Again "Pass by reference" is "well defined" in computer languages.

Passing a reference to an object is not "pass by reference". Your example works the same in Java and C# and probably Swift and many other languages. But you aren't "passing by reference". "pass by reference" specifically means passing a reference to the variable, not the variable's value. Javascript always passes the value of the variable, it has no ability to pass a variable by reference.

Re: Comparing Svelte and React

#335
post #325
post #301

Earlier quoted context omitted.

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.

Sure, but if massive amounts of people disagree with that take and think the library is strong, intuitive, and best-in-class, maybe someone is just struggling with understanding the structure of the library

Re: Comparing Svelte and React

#336
post #310
post #301

Earlier quoted context omitted.

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.

Can you speak to these bugs? I personally don't agree that React apps impart any standard class of bugs, but maybe that's because Redux is actually the source of all these issues and I've avoided redux like the plague it is

example app: airbnb when you get messages. click a message. and you'll see it will still have an indicator that you've a message, when you've none. airbnb guys are some of the best react guys out there even released open source libraries like enyzme etc. fact is no one can ever get the react thing right. don't get me started on facebook. plenty of bugs in their new app. But for some reason, instagram web is polished.

Re: Comparing Svelte and React

#337
post #310
post #301

Earlier quoted context omitted.

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.

Can you speak to these bugs? I personally don't agree that React apps impart any standard class of bugs, but maybe that's because Redux is actually the source of all these issues and I've avoided redux like the plague it is

nice point on pointing out the redux part. yeah most times it's the point of bugs - state mismatch etc.

Re: Comparing Svelte and React

#338
post #168

Earlier quoted context omitted.

I was saying elsewhere on the thread - I am not suggesting that each should be turned into a runtime call. Instead, 'svelte.each()' callsites are easy to identify in the AST and transform in the compiler. So the errors remain compile-time, not run-time.

The danger is that a developer will use `svelte.each()`, thinking it uses the same rules as normal JS syntax, but it turns out Svelte applies its own rules which _are_ slightly different (hypothetically). So the developer must remember a new rule: "JS rules when calling foo.each(), Svelte rules when calling svelte.each()". A little harder to remember. Having a unique non-JS syntax makes the distinction obvious. (Just…

That's a pretty reasonable argument and I believe a big part of what makes hooks somewhat complex since they look like regular Javascript but can behave differently.
Post reply on HN