Hacker News Reader

Comment by jitl | Hacker News Reader

You can implement a hooks like interface in an afternoon. I don’t think I could do the same for Svelte’s compiler-oriented approach. Using a compiler means that Svelte is essentially a dialect of EcmaScript, which appears to be mutually intelligible but isn’t always. React used a compiler for JSX which also introduced a dialect, but JSX is optional and very straightforward sugar for a simple function call. The Svelte dialect is not so simple.

View on HN

> Using a compiler means that Svelte is essentially a dialect of EcmaScript

So are hooks. The fact that you can't put regular function calls (which hooks look like) in an if statement, or have to provide custom "dependency lists" to some of them, or that data returned from them suddenly re-renders (aka calls again) the function they are in tells you that this is no longer regular Javascript.

Exactly, I don't get the React is just Javascript. It's not. You're tied to React just as much as Svelte or anything else. The Facebook propaganda machine is clever I will say.

There’s a wide difference between learning the semantics of an API and learning the semantics of a custom language with a compiler. There are alternate implementations of the React API, like Preact. The semantics of the React API might be complex, but you could implement them in essentially any programming language with function pointers and variable length arrays. You can’t say the same thing for Svelte; which we know is impossible to implement in pure JavaScript, which is why it needs a compiler. This is all anyone in this thread is arguing - it’s an argument about semantics but for some kinds of environments semantics are very important.

I’ve helped teams pilot out of own-the-world frameworks like Backbone and Rails before (both of which substantially distort the runtime they’re embedded in); but it was much harder to deal with Backbone + Coffeescript together. For Backbone w/ vanilla JS or Rails, we could use standard static analysis tools, Coffeescript added a big extra wrinkle to our migration.

Yes and no. They definitely push the boundaries, and the framework imposes certain extra restrictions on how it wants you to use them, and they warp your normal intuitions a bit. But at the end of the day they are just function calls. They don't compile down to some other sort of construct with totally different language semantics.

There's a fundamental difference between a framework that takes your code and does weird things with it, vs a framework that rewrites the semantics of your code out from under you.

Yes, they push the boundaries and essentially create a DSL with its own rules that do change semantics of the language. Not as drastically as a custom compiler, but they still do.

They specifically do not change the semantics of the language, they create a new abstraction on top of it that has unusual semantics.

Reply on news.ycombinator.com