Hacker News Reader

Comment by xrd | Hacker News Reader

I really love Svelte. The compiler is great and very extensible. For example, you can easily add functions to the processing pipeline to process Svelte templates (or the script elements or style sections) in your own special way. It's a fantastic way to build JavaScript frameworks. Svelte people always note Svelte isn't a framework, so this isn't a framework on top of another framework!

I used this to build Svekyll, a Jekyll clone (the original static blog tool).

https://extrastatic.dev/svekyll/svekyll-cli

Not to toot my own horn, but I'm really proud of it. Svekyll scores all 100s with lighthouse but still has all the cool things you get from a Svelte app. It's a true single page app, all JS is inlined and can be put on any web server for hosting. Plus, a bunch of other cool things that only are possible with a native JS blog.

View on HN

I also like svelte but as a compiler-y person who happens to be doing some JS I can't work out why I'm annotating so much stuff by hand (even with svelte 5). I can get why you might want this for react, but isn't svelte a compiler? Can't we do dataflow analysis?

I'm 50% convinced there's a Chesterton's fence I'm mising but where?

Kind of an aside, but I can’t stand how in Svelte the statement “foo = foo” is semantically meaningful.

I think this will no longer be necessary in Svelte 5. We’ll see.

I believe the constraints chosen could be summarized as

1. the code you write must parse as valid JS

2. you must be able to write traditional JS

3. we want the equivalent of the Destiny Operator https://paulstovell.com/reactive-programming/

You can only do so many compiler-y things in a dynamically typed language like Javascript. And even less of it within the context of a single file, unless you implement a bundler (web jargon equivalent of linker). Otherwise by the time the run-of-the-mill bundler is done connecting parts of your component tree into a single file, so much of the high-level information of the component is lost that you can't really do much analysis on it.

At least that were the reasons I saw when I was thinking about the same. If anyone has ideas around it, please get in touch.

But with a svelte component it knows a lot about the state, inputs, outputs etc.

The default paths should be pretty easy to analyze as long as you pick sensible defaults.

It sounds like you would appreciate Vue3 and its <script setup> mode, the compiler does a lot of ref() and data flow analysis to make the code for components very readable.

I love svelte too but I've found it hard to integrate it in different places where I may run js (e.g. obsidian plugins, browser plugins). It was hard to configure the necessary tooling but maybe it's not sveltes fault. I think svelte would really benefit from better documentation on how to do this (and I don't mean sveltekit documentation). It was also at least non-trivial to use with typescript and even more non-trivial to have some third-party dependencies/components that don't use typescript. Again, maybe not sveltes fault and hard in every framework but those were my show-stopping issues the last time I tried to build something real in svelte.

Interesting. I think you should ask some questions inside the Svelte discord channel. My opinion is that Svelte is the easiest to integrate because it doesn't require the runtime that react does, for example. I've got Svelte running inside lots of non standard places, like browser extensions (https://addons.mozilla.org/en-US/firefox/addon/please-at-me/). It can take a few minutes to figure out how to get it built correctly for the context but it has never blocked me.

I don't disagree about your typescript point. Svelte community seems to have aligned around typescript being a challenge and I do like their assertion that jsdoc+eslint is a better approach.

Until svelte can have a client-side router builtin, and treat SPA as its first class citizen(the way Vue.js does so far. React also shifts to SSR-SPA mixed situation jus like svelte, both are impacted by Vercel, which is really sad), instead of just focusing on its sveltekit SSR-first, I have zero interest in it. Yes I know I can customize sveltekit to do SPA, but it's very ugly and I don't need all your SSR mental load to an already complex frontend world.

Both Svelte and React are shifting to SSR-first, which is what Vercel can make money with, I read somewhere Vercel had many React core members now, after it bought out Svelte.

Svekyll was originally built on sveltekit and I couldn't figure out how to get SSR and figure out the right adapter for nodejs and static hosting. Which is why I abandoned it and am much happier with a Svelte only CLI, just like Jekyll.

Or, rather than being some great conspiracy, SSR (or as we used to call it, just rendering) makes a great deal of sense.

What goes around, comes around. It has always felt like the front-end frameworks, from things like Backbone to React always failed to learn the lessons of history. Preoccupied with being "new" in an area that's rapidly gaining capabilities via the browser.

Re-inventing the wheel isn't difficult. Improving it is.

Someone some day should write an article about frameworks with examples that show it's advantages.

I just try different things in vanilla depending on the load. In terms of speed nothing can beat just serving a page rendered on the server. If you really need dynamic updates replacing dom nodes is good up to some very limited number, virtual dom and cloned nodes increase this number by a tiny irrelevant amount. If you need to update more than 100 nodes, from what I've tested, nothing beats replacing the parent node content with a html string. Sometimes inline onclick="" handlers are great compared to creating 1000 listeners one by one. Sometimes you put the listener on the parent and figure out what was clicked when it happens. I've even had cases where iframes are wonderful. At times I also put some or many hidden nodes in the html document and display them when needed.

Writing this I'm curious what the performance is for <output>....

https://jsfiddle.net/4ajzcfw9/

(Didn't feel like doing it right)

This is the basis of HTMLX, a framework for tree replacement with server-side rendered HTML

True. The drive to SSR is caused by the rise of battery-constrained mobile devices with unreliable wireless connections, along with the rise of cloud computing.

I recently used a Windows 10 machine after years and I suggest you try it. It could not be more evident that Microsoft is fully betting on Web and Cloud. Windows is increasingly a thin client. Even the mail app isn’t an actual mail client now.

Toot your horn because your project is really great. I blog with SvelteKit, and your way has many improvements galore. Thank you for sharing this!

That's so cool of you to say this. Please email me at chris@extrastatic.com with any questions or feedback!

And, as a bonus I'll share all the warts with you! It's not perfect but I love blogging with it.

Reply on news.ycombinator.com