Svelte components compile to vanilla javascript plus a small runtime (a dozen or so functions that track state for context and the developer tools). It's much lighter weight than React or Vue's runtime and a side effect is that integrating Svelte components into other frameworks is a breeze (especially if you compile to web components). The author refers to it more as a separate language.

I've had a great experience with it recently developing a smart tv app - which are dog slow even with a quad core ARM CPU due to the resolution so I decided to learn Svelte for the project. The big downside is another templating language to learn and as you said, the community is tiny, but the surface area is small enough that it hasn't been a problem regarding tooling or debugging. Pulling in other frameworks into a svelte app is also relatively easy so it can be part of a slow incremental rewrite, although as always it devolves into a webpack/rollup config mess.

> Svelte components compile to vanilla javascript plus a small runtime

Same could be said of React though. React components are literally just plain JavaScript functions which return VDOM nodes that get diffed and applied to the DOM by the runtime library.

The only objective advantage I see to Svelte is it's tiny footprint, which if you really need you can already get by using Preact (3kb vs Svelte's 3.5kb) without having to learn yet-another-completely-arbitrary-templating-language to no benefit.

Svelte is actually quite a bit different. Quoting a random section from their docs

"[Svelte is a] compiler that knows at build time how things could change in your app, rather than waiting to do the work at run time"

My point being there is a large amount of compile time code transformation at build time. The run time is not so much a framework as a library like libc. In Svelte when you update state there is no virtual dom, dom diffing, fibers, or anything. It would have been compiled into a direct dom update of anything depending on it. It's no longer a Svelte app just vanillajs. There are some details or course but it's a different paradigm than to react or other modern UI frameworks.

And without a virtual dom and all of its overhead.

Virtual dom isn’t that expensive compared to modifying dom. Svelte isn’t magical, it’s still diffing objects to figure out whether to change some dom element’s attributes

With react memoization and pure components, you get very similar benefits.

Sure svelte goes the extra step and removes unnecessary diffing of constant attributes that will never change and other opts. However there are tradeoffs

>When did software engineers become hipsters?

Hacker News is the epicenter of software engineer hipsterdom, come on.

That's true. I guess I'm just frustrated by that. I suppose I should just accept it and let it go haha.

It seems like a lot of web devs are either stuck chasing novelty or constantly trying to bet on the next big thing.

For example, what happened to CoffeeScript? https://trends.google.com/trends/explore?q=%2Fm%2F0hjc5m0&ge...

What happened to Ember? https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0s8...

TypeScript ate coffeescript. That said it did inspire a lot of new features in both TypeScript and the ES standard.

Ember is still going strong, Octane is a fantastic new release and it’s been awesome to un-learn all the ember specific things in favour of all the new vanilla JS ways of doing things that Octane makes possible.

About the only negatives I can bring up are IDE (and other sorts of vendor tools/components) support/integration is not as good as more popular frameworks like React, but that’s really just to be expected as vendors tend to target based on popularity.

Coffeescript was 'replaced' by ECMAScript 2015. Ember is fine but it's not the end of the line - it's been superseded' in most scenarios by React and Vue.js because those are generally better tools.

JS technology changes quickly not for its own sake, but because there are still discoveries to be made about how to improve both syntax and how we think about code. I'm sure the pace will taper off sooner or later, until the Web is taken over by something else.

It’s also because JS raced to integrate features which were considered standard elsewhere, back in the dark ages with anonymous self executing functions.

I think you're right. But I think that's because it's still early days, nobody has really nailed it yet. We're all trying to make sure that when something sticks, we'll be ready for it. It seems like TypeScript and React are sticking around pretty good. I'm sure they'll be replaced at some point. My personal hope is that they'll be replaced by better standards within the browser.

CoffeeScript largely got killed by EcmaScript 6.

Two reasons why

1) Some CoffeeScript features, like arrow functions and classes, made it into ES6. 2) CoffeeScript was never updated to properly generate ES6. Largely because the features that got adopted by ES6 had subtle differences that made the migration path for existing projects highly complex.

I think, to a lesser extend, the rise of TypeScript also had something to do with it.