Hacker News Reader

Comment by MatekCopatek | Hacker News Reader

You typically write in one language and the compiler produces something lower-level out of it. In this case, you write vanilla JS and get (different) vanilla JS.

View on HN

I argue that transpilation done by tools like Svelte or Babel is just compilation in a broader sense. I don’t see the seemingly relevant difference here.

You can write and run React/Preact based applications "as is" without using a transpiler like Babel (you just typically do to minify code and use more fancy javascript features). You can't run a Svelte based application without precompiling it using the Svelte compiler.

The essential feature of it is that it’s a compiler. Things in general get easier to debug over time as they get improved, the basic concept is actually a very powerful. I’m a fan of svelte for the small things I’ve tried it on; there’s always growing pains with learning curves.

Yeah, I do agree. That was not a critic of Svelte, just a comment about that there is a difference between compilation (Svelte) and transpilation (Babel). I do use Svelte in every day job myself and prefer it to React (which is also great) just because writing Svelte "feels" like what Javascript has intended to be.

You are not supposed to look at the output code. The only relevant thing is if it does what it's supposed to do.

some times, not very often it is true, you need to look at the output to figure out why your code is not doing what it is supposed to do.

As an example, I'd argue that the output of the Svelte compiler is surprisingly understandable.

https://svelte.dev/repl/f104bac93c9c48f5bd18322e3b9b9425?ver...

in comparison to what comes out of some webpack things I've looked at, yes it looks more readable. Offhand I don't agree with all their undefined lets there, but not a big issue either.

All those undefined lets are part of how Svelte components are constructed, and it can’t be done in any other way across the board. It may not be how you’d write such things manually, but for compiler output it’s sane. For simple cases like that one, the create (c) lifecycle method could essentially be shifted up into the let statements, but for some more complex cases that couldn’t be done, and if hydration is enabled it definitely can’t be done, because those variables can then be filled in one of two ways, creating (c) new nodes or claiming (l) existing nodes.

Are you kidding? It's at some point understandable when looking a minute at it, but this only a small hello world app. How will you be able to understand the generated code with a few dozen components and much more logic?

Great demo, even though I don't agree that it is easy to understand.

I have to try a larger program and see what it emits but I don't think junior developers will think it is easy. And trying to find your bugs if you connect things to the wrong component/part might be very hard to spot. I still think React dev tools are way nicer.

Sure, but are people looking at the artifacts that other frameworks generate? I think generated code is mostly interesting to the framework devs themselves and not to most others.

as I said, seldomly, but I did have to spend several days recently looking over webpack output to figure out what was wrong.

Also I remember one time in a previous consulting job a developer who was not very good had used an instruction to not show something if env was prod, but forgotten to end if, which caused module compilations using the horrendous babel/gulp setup to break in the middle of one module but finally start working again in another one, meaning that there were parts of the applications that were trying to refer to a module # 31 or something like that which was no longer present in the big object that was put out of compiled modules. (this is like 3-4 years ago now)

Since it was not showing something if env was prod, if env was dev no problem.

That meant I had to take the output of the prod build and walk through comparing with dev build to figure out what modules were not compiled in, and then figure out from that were the likely error was and then looking in those places with git blame to say what was done wrong.

Reply on news.ycombinator.com