6 ms·

> I doubt I'll ever voluntarily use one of those frameworks for web dev. > I do, however, like this thing called, Svelte. Svelte is just another one of “those

> I doubt I'll ever voluntarily use one of those frameworks for web dev. > I do, however, like this thing called, Svelte. Svelte is just another one of “those frameworks”, except with a vastly smaller community: https://trends.google.com/trends/explore?geo=US&q=svelte%20is,react%20js,angular%20js,vue%20js https://trends.google.com/trends/explore?geo=US&q=svelte%20i...

x3haloed 7y ago
It's better than everything else because people have never heard of it. When did software engineers become hipsters?
- nefitty 7y ago
  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&geo=US https://trends.google.com/trends/explore?q=%2Fm%2F0hjc5m0&ge... What happened to Ember? https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0s8wr70 https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0s8...
  - hyperdunc 7y ago
    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.
    - threatofrain 7y ago
      It’s also because JS raced to integrate features which were considered standard elsewhere, back in the dark ages with anonymous self executing functions.
  - ng12 7y ago
    TypeScript ate coffeescript. That said it did inspire a lot of new features in both TypeScript and the ES standard.
  - techdragon 7y ago
    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.
  - realityking 7y ago
    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.
  - x3haloed 7y ago
    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.
- deleted 7y ago
  [deleted]
- krapp 7y ago
  >When did software engineers become hipsters? Hacker News is the epicenter of software engineer hipsterdom, come on.
  - x3haloed 7y ago
    That's true. I guess I'm just frustrated by that. I suppose I should just accept it and let it go haha.
cjbassi 7y ago
And without a virtual dom and all of its overhead.
- nojvek 7y ago
  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
akiselev 7y ago
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.
- wyqydsyq 7y ago
  > 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.
  - pests 7y ago
    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.

x3haloed 7y ago

It's better than everything else because people have never heard of it. When did software engineers become hipsters?

nefitty 7y ago
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&geo=US https://trends.google.com/trends/explore?q=%2Fm%2F0hjc5m0&ge... What happened to Ember? https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0s8wr70 https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0s8...
- hyperdunc 7y ago
  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.
  - threatofrain 7y ago
    It’s also because JS raced to integrate features which were considered standard elsewhere, back in the dark ages with anonymous self executing functions.
- ng12 7y ago
  TypeScript ate coffeescript. That said it did inspire a lot of new features in both TypeScript and the ES standard.
- techdragon 7y ago
  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.
- realityking 7y ago
  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.
- x3haloed 7y ago
  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.
deleted 7y ago
[deleted]
krapp 7y ago
>When did software engineers become hipsters? Hacker News is the epicenter of software engineer hipsterdom, come on.
- x3haloed 7y ago
  That's true. I guess I'm just frustrated by that. I suppose I should just accept it and let it go haha.

cjbassi 7y ago

And without a virtual dom and all of its overhead.

nojvek 7y ago
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

akiselev 7y ago

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.

wyqydsyq 7y ago
> 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.
- pests 7y ago
  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.