10 ms·

Svelte – The magical disappearing UI framework

165 points by ergot 10y ago

achikin 10y ago
Should I feel happy that my js crap compiles into the other js crap?
- Traubenfuchs 10y ago
  You don't get it: Your js crap compiles to other js crap, yes, but this time your other js crap is BETTER than other peoples js crap who don't use Svelte because apparently downloading an executing 70 kb vue.min.js gzipped to 26 kb is just too much for the toasters people allegedly use to execute your TodoMVC application.
  - tracker1 10y ago
    Depends on what you're targeting.. a lot of the media stick interfaces, and cheap android phones are pretty under powered. Of course, it also depends on application complexity and types of interaction, animation, etc. I've found React proper does a pretty decent job of running everywhere I've needed, though I have used preact for smaller extensions, and bits that are adding to an existing app, where I want to add new React-style code, to keep the size down.
jc4p 10y ago
Looks to have connectivity with gulp, browserify, webpack, system.js, a lot of stuff. That's rad! I wish it had easier samples to show what the code you write looks like. I have a couple questions just off the homepage that I didn't quite really get answered: - Can I use webpack? Can I add this into my current webpack flow? - Can I use TypeScript? - How does this compare to preact? Note that their homepage has a lot more info than this one: https://preactjs.com/ https://preactjs.com/
- jacobmischka 10y ago
  - Yes: https://github.com/sveltejs/svelte-loader https://github.com/sveltejs/svelte-loader - Unsure - Preact is essentially a lightweight implementation of React. As such, it requires a runtime, albeit an incredibly small one, to dynamically render HTML from JSX (Edit: Well, compiled JSX. Essentially hyperscript function calls.). Svelte components compile at buildtime to pure es5, so you can just run it directly on the client without a runtime. There are benefits and drawbacks to each method, but that's the gist of their main differences.
  - jc4p 10y ago
    Sorry if I'm just not getting it. is it compiling some nice language I write into some JS that runs compile time? Or is this a static website generator? If I use Svelte to make my site, is the expectation that the data is being loaded in the cacheable HTTP call or is it a SPA?
    - allover 10y ago
      Check the REPL and compare the input to the output: https://svelte.technology/repl https://svelte.technology/repl
- jaeh 10y ago
  you can have a look at https://github.com/jaeh/meds https://github.com/jaeh/meds to see an example, online at https://jaeh.github.io/meds https://jaeh.github.io/meds basically an offline first app that i developed both because i needed it and because i wanted to have a look at svelte.
- rich_harris 10y ago
  > I wish it had easier samples to show what the code you write looks like If you visit the REPL you can click on the 'output' button to see some sample output code: https://svelte.technology/repl https://svelte.technology/repl > Can I use webpack? Yep, there's a webpack loader: https://github.com/sveltejs/svelte-loader https://github.com/sveltejs/svelte-loader > Can I use TypeScript? Integration with things like TypeScript is on the nice-to-have list — we have an issue here: https://github.com/sveltejs/svelte/issues/58 https://github.com/sveltejs/svelte/issues/58 > How does this compare to preact? Last time I checked, Svelte was faster. Need to get some automated benchmarks up and running, and compare sizes (and parse & startup time) for equivalent non-trivial apps.
purity_resigns 10y ago
Interesting that Rich Harris is also behind rollup and that Svelte appears to use CommonJS instead of ES modules still.
- rich_harris 10y ago
  It's built out of ES modules (and is bundled by Rollup) but it can compile components to ESM, AMD, CJS, UMD or a browser global, so it can be made to work with just about any setup.
cohort 10y ago
Been hoping this would get some more traction. Blog post is a good starting point for those interested... https://svelte.technology/blog/frameworks-without-the-framework/ https://svelte.technology/blog/frameworks-without-the-framew...
taspeotis 10y ago
Previous discussion [1] Svelte – A UI framework that compiles into tiny standalone JavaScript modules (svelte.technology) 533 points by bpierre 38 days ago | 228 comments [1] https://news.ycombinator.com/item?id=13069841 https://news.ycombinator.com/item?id=13069841
matchu 10y ago
I'm confused by the anti-runtime argument. The file size problem is about unused code, right? If we tree-shook the runtime and shipped the minimal version that our app needs, wouldn't that be even better for most apps than inlining the framework? I'd expect that, the moment you use a feature even twice, the runtime approach yields a smaller bundle. Or is Svelte accepting a file size penalty to avoid the performance overhead of function calls? If so, it'd be nice to see that tradeoff discussed more explicitly: in every app, there are probably features worth inlining and features worth keeping as function calls. Really, it sounds like Svelte is trying to solve a very general compilers problem with a very specific sledgehammer solution. Sure, tree-shaking and thoughtful inlining are difficult to do well, especially in Javascript, so this makes sense as a first draft for certain use cases. I just wish it were touted as a first draft, rather than a new beautiful finished paradigm.
- pedalpete 10y ago
  I took the runtime to be the bootstrap time of the framework before your code actually runs, but I could be wrong. I'd like to see some performance metrics from Svelte compared to page loads with other frameworks to see where the savings are.
- rich_harris 10y ago
  > If we tree-shook the runtime and shipped the minimal version that our app needs I've heard this sentiment a lot. The reality is that UI libraries are inherently difficult to tree-shake. You can't run a library that can be used to produce an infinite range of outcomes and expect a tool like Rollup to whittle it down to just the bits you need (source: I'm the creator of Rollup). Code is reused. While the compiler will output 'standalone' modules by default, it can also generate modules that share code between components — the zero-runtime part is about generating abstraction-free DOM manipulation code rather than having a complex virtual DOM reconciliation or data-binding process. > rather than a new beautiful finished paradigm Nowhere does it claim to be finished. If anything, it's the start of a new approach to building UIs.
  - matchu 10y ago
ricardobeat 10y ago
Has anyone done further testing on the growth rate of the compiled code for larger projects? From the discussion when this launched it seems like the difference will be mostly felt by smaller apps. That aside, being able to write 'universal' components that work independently of a framework is still a great thing to have.
- rich_harris 10y ago
  Since launch we've added the ability to generate code that reuses functions between components. If you use the CLI it will create 'standalone' modules, but if you use something like https://github.com/rollup/rollup-plugin-svelte https://github.com/rollup/rollup-plugin-svelte then code will automatically be reused.
aaronfc 10y ago
Whenever and wherever I read "rock solid" I stop reading... I hate that expression so much!
- aarpmcgee 10y ago
  Why?
  - the_duke 10y ago
    I agree. Whenever I read 'rock-solid' my distrust alarm goes off and it's almost always reading some buzzword laden marketing text.
  - Nekorosu 10y ago
    Because it expresses the authors confidence but doesn't give anything informative. Show me metrics, features, idioms and working examples.
    - proyb2 10y ago
      Meanwhile, you can download and try the sample code. https://github.com/sveltejs https://github.com/sveltejs I spent a few days testing and it was an eye opener, compare to the numbers of >100 outstanding issues filed in React, Angular, etc which may probably never fix it for some reason and complexity.
      - tracker1 10y ago
        Something tells me, should svelt get to the number of stars that React and Angular have, you'll see a similar number of issues.
        proyb2 10y ago
        We need a robust testing system to reduce bugs, improve performance and do some recommendation where code quality can be simplify or better security. I believe not many community can affordable the time to write testing, even expertise skived and problem appear at compile time.
gigatexal 10y ago
How does anyone even begin to start learning how to make Web 2.0 webpages with a new JS framework every week?
- greyskull 10y ago
  If you can't afford to be on the cutting-edge, you use battle-tested technologies, and let the people who can afford it do their thing to shake out which products are worth keeping around. That's sort of the right approach for any software development, yeah?
  - innocentoldguy 10y ago
    Yeah, but most other technologies don't have new libraries and frameworks coming out every other day. For example, with Ruby, the community has stuck with Rails and Sinatra for more than a decade now. With Python, most developers go with Django or Flask. With Elixir, Phoenix or Plug. With Javascript/Node, however, you have Hapi.js, Sails.js, Mean.js, Koa, Socket.io, Mojito, Express.js, Meteor, Mithril.js, Derby, and others, not to mention the front-end options, like Angular, React, Svelte, etc., Some of these frameworks are even written by the same developers to accomplish largely the same thing (e.g. Express vs. Koa). This doesn't seem like a great strategy for long-term success. It got to the point with me that I didn't want to invest any more time in Javascript technologies, simply because their lifespans seemed to be quite short, compared to other options. In the Javascript community, framework feel disposable. I don't mind learning, but there has to be time for implementation and mastery, and there has to be some level of long-term career payoff for the time invested in learning. For example, I can still get any number of Rails jobs after 11 or 12 years of using the framework. Can the same be said of the original Express.js? I know it isn't a comprehensive, scientific study, but a quick search on local job boards in my area turns up 15 Rails jobs, and no Express.js jobs. No Hapi.js jobs. No Metor jobs. No Mithril.js jobs. No Derby jobs. I don't mean to take away from the successes the Javascript community has had over the years. Javascript is certainly in a better state than it was a decade ago. However, having so many libraries and frameworks come and go so quickly isn't a good thing, in my opinion. I think the community could benefit a lot by embracing more cohesion and focus, but that's just my opinion, based on my experience with other languages and communities.
revelation 10y ago
Code generation, the frontend craze must have arrived at the Java enterprise deadends. Time to mount the JET emitters and blast out that code.
laughingman2 10y ago
I think with advent of Inferno, 9KB for a view layer runtime, which has overhead of just 4% above vanilla JS is acceptable for me to compiled view layer that repeats code everywhere.
soperj 10y ago
It's funny that everyone on here is pretty critical of this. To the maker, don't pay any attention, your users will give you much better feedback.
- rich_harris 10y ago
  Thanks! Don't worry, this ain't my first rodeo :-D Just glad for the opportunity to help clear up any misconceptions people have, it's always useful to get feedback about how we can better communicate the ideas.
simplify 10y ago
How does this compare with Marko.js, which also compiles (and renders!) JavaScript on the server before sending to the client?
kensign 10y ago
I think http://aurelia.io http://aurelia.io is much cleaner.
- proyb2 10y ago
  Cleaner as in? Aurelia is on the same idea as Angular 1 by the same inventor.
fenollp 10y ago
So the core idea is similar to https://github.com/purifycss/purifycss https://github.com/purifycss/purifycss but for JS code. Then why does Svelte wants to be yet another framework? Do a real good one to the world and be something that you can plug into Gulp or a Makefile...
- rich_harris 10y ago
  Not really similar at all. It's a compiler, not just a code removal tool. > Do a real good one to the world and be something that you can plug into Gulp or a Makefile... You can easily use Svelte in Gulp tasks or Makefiles. Maybe do a tiny amount of research before criticizing something. God the HN crowd is tedious sometimes
  - arxpoetica 10y ago
    Ha!
nkkollaw 10y ago
Can I say something shallow? I talked to a couple of programmers about the project, and they laughed at me because of the name, dismissing the project and not even wanting to hear about it. Everyone keeps saying that the name is not important, citing examples like Yahoo, Google etc., but it is. I was reading about how execs didn't want to replace Android with Cyogenmod, and I bet part of the reason is the name. It's hard to pronounce, it contains "mod" in it, and it sounds like a tool for hackers instead of a reputable operating system that corporate would be ok having on all their phones. "Svelte" sounds like a name for a dish washer brand.
- rich_harris 10y ago
  'Svelte' means 'slender and elegant', 'urbane', 'attractively thin, graceful, and stylish', or 'lithe', depending on which dictionary you consult. It comes from the Italian svelto meaning 'quick'. Those are all excellent connotations! But yes, it seems that a lot of people, at least here in the US, aren't familiar with the word. It doesn't matter though. I build tools for my job because the existing ones don't meet my needs, and then I share them because there's no good reason not to. I couldn't care less whether or not people use them as long as the ideas get out there. So if someone decides not to use Svelte because they don't like the name, all I do is shrug.
  - halfdan 10y ago
    They should probably release an americanized version called "swell" - http://www.urbandictionary.com/define.php?term=swell http://www.urbandictionary.com/define.php?term=swell
  - nkkollaw 10y ago
    I'm from Italy and so were 2 of my programmer friends. We're used to English, though. The other guy is from Sweden. I wonder if it sounds better to people whose first language is English. It doesn't seem like you care (I guess rightfully), just a note.
- coldtea 10y ago
  >I talked to a couple of programmers about the project, and they laughed at me because of the name, dismissing the project and not even wanting to hear about it. Clearly a sign that you should avoid listening to said programmers on any important matter from now on, because they are 16-year olds inside (not to mention they haven't even bothered to open a dictionary in their lives). Reminds me of people that laughed at iPad's name (because of the maxi-pad connotations).
bastijn 10y ago
"In Svelte, an application is composed from one or more components. A component is a reusable self-contained block of code that encapsulates markup, styles and behaviours that belong together." So, the idea is to be kind of like Web components? Even after reading the comments in this thread and the website it is hard for me to grasp where Svelte's place is. Is it for people who need the performance without giving up the work flows of the regular frameworks they are so used to? If it is for encapsulation I would say webcomponents is the better choice here? Although you could argue Web components isn't ready yet either for the big masses.
- rich_harris 10y ago
  Very much like web components, except a) they work everywhere without polyfills, and b) they're nicer to build, because they have a friendlier API and templates are more declarative (with web components you still have to do a lot of grubby manual DOM manipulation) and you don't have to learn a bunch of confusing new shadow DOM stuff just to encapsulate styles. Also, with Svelte you can do server-side rendering, which is a bit of an oxymoron with web components.
  - bastijn 10y ago
    a) is a bit of a weak argument as polyfills are a temporary solution until browser support is available everywhere. Also, Web components are (indirectly) part of the W3C spec so browser support will follow. B) OK. Though subjective. C) Active support for this is a nice thing to have. Guess it ain't enough for me to use hut I see its use for others. Still, YAJF as far as I'm concerned.
    - rich_harris 10y ago
      > polyfills are a temporary solution until browser support is available everywhere Well, you might be waiting a while! Web components are actually four separate specs. While templates are widely supported, the future for custom elements, shadow DOM and HTML imports is less clear (well it's very clear for HTML imports — it ain't gonna happen). Edge is 'considering' whether to implement shadow DOM and custom elements, Firefox says they're 'in development' but from the outside it looks like that development has stalled. Even if web components had major advantages that outweighed their disadvantages, personally I'd be very hesitant to use them until browser vendors make their intent to support them much clearer.

165 points by ergot 10y ago

achikin 10y ago

Should I feel happy that my js crap compiles into the other js crap?

Traubenfuchs 10y ago
You don't get it: Your js crap compiles to other js crap, yes, but this time your other js crap is BETTER than other peoples js crap who don't use Svelte because apparently downloading an executing 70 kb vue.min.js gzipped to 26 kb is just too much for the toasters people allegedly use to execute your TodoMVC application.
- tracker1 10y ago
  Depends on what you're targeting.. a lot of the media stick interfaces, and cheap android phones are pretty under powered. Of course, it also depends on application complexity and types of interaction, animation, etc. I've found React proper does a pretty decent job of running everywhere I've needed, though I have used preact for smaller extensions, and bits that are adding to an existing app, where I want to add new React-style code, to keep the size down.

jc4p 10y ago

Looks to have connectivity with gulp, browserify, webpack, system.js, a lot of stuff. That's rad! I wish it had easier samples to show what the code you write looks like. I have a couple questions just off the homepage that I didn't quite really get answered: - Can I use webpack? Can I add this into my current webpack flow? - Can I use TypeScript? - How does this compare to preact? Note that their homepage has a lot more info than this one: https://preactjs.com/ https://preactjs.com/

jacobmischka 10y ago
- Yes: https://github.com/sveltejs/svelte-loader https://github.com/sveltejs/svelte-loader - Unsure - Preact is essentially a lightweight implementation of React. As such, it requires a runtime, albeit an incredibly small one, to dynamically render HTML from JSX (Edit: Well, compiled JSX. Essentially hyperscript function calls.). Svelte components compile at buildtime to pure es5, so you can just run it directly on the client without a runtime. There are benefits and drawbacks to each method, but that's the gist of their main differences.
- jc4p 10y ago
  Sorry if I'm just not getting it. is it compiling some nice language I write into some JS that runs compile time? Or is this a static website generator? If I use Svelte to make my site, is the expectation that the data is being loaded in the cacheable HTTP call or is it a SPA?
  - allover 10y ago
    Check the REPL and compare the input to the output: https://svelte.technology/repl https://svelte.technology/repl
jaeh 10y ago
you can have a look at https://github.com/jaeh/meds https://github.com/jaeh/meds to see an example, online at https://jaeh.github.io/meds https://jaeh.github.io/meds basically an offline first app that i developed both because i needed it and because i wanted to have a look at svelte.
rich_harris 10y ago
> I wish it had easier samples to show what the code you write looks like If you visit the REPL you can click on the 'output' button to see some sample output code: https://svelte.technology/repl https://svelte.technology/repl > Can I use webpack? Yep, there's a webpack loader: https://github.com/sveltejs/svelte-loader https://github.com/sveltejs/svelte-loader > Can I use TypeScript? Integration with things like TypeScript is on the nice-to-have list — we have an issue here: https://github.com/sveltejs/svelte/issues/58 https://github.com/sveltejs/svelte/issues/58 > How does this compare to preact? Last time I checked, Svelte was faster. Need to get some automated benchmarks up and running, and compare sizes (and parse & startup time) for equivalent non-trivial apps.

purity_resigns 10y ago

Interesting that Rich Harris is also behind rollup and that Svelte appears to use CommonJS instead of ES modules still.

rich_harris 10y ago
It's built out of ES modules (and is bundled by Rollup) but it can compile components to ESM, AMD, CJS, UMD or a browser global, so it can be made to work with just about any setup.

cohort 10y ago

Been hoping this would get some more traction. Blog post is a good starting point for those interested... https://svelte.technology/blog/frameworks-without-the-framework/ https://svelte.technology/blog/frameworks-without-the-framew...

taspeotis 10y ago

Previous discussion [1] Svelte – A UI framework that compiles into tiny standalone JavaScript modules (svelte.technology) 533 points by bpierre 38 days ago | 228 comments [1] https://news.ycombinator.com/item?id=13069841 https://news.ycombinator.com/item?id=13069841

matchu 10y ago

I'm confused by the anti-runtime argument. The file size problem is about unused code, right? If we tree-shook the runtime and shipped the minimal version that our app needs, wouldn't that be even better for most apps than inlining the framework? I'd expect that, the moment you use a feature even twice, the runtime approach yields a smaller bundle. Or is Svelte accepting a file size penalty to avoid the performance overhead of function calls? If so, it'd be nice to see that tradeoff discussed more explicitly: in every app, there are probably features worth inlining and features worth keeping as function calls. Really, it sounds like Svelte is trying to solve a very general compilers problem with a very specific sledgehammer solution. Sure, tree-shaking and thoughtful inlining are difficult to do well, especially in Javascript, so this makes sense as a first draft for certain use cases. I just wish it were touted as a first draft, rather than a new beautiful finished paradigm.

pedalpete 10y ago
I took the runtime to be the bootstrap time of the framework before your code actually runs, but I could be wrong. I'd like to see some performance metrics from Svelte compared to page loads with other frameworks to see where the savings are.
rich_harris 10y ago
> If we tree-shook the runtime and shipped the minimal version that our app needs I've heard this sentiment a lot. The reality is that UI libraries are inherently difficult to tree-shake. You can't run a library that can be used to produce an infinite range of outcomes and expect a tool like Rollup to whittle it down to just the bits you need (source: I'm the creator of Rollup). Code is reused. While the compiler will output 'standalone' modules by default, it can also generate modules that share code between components — the zero-runtime part is about generating abstraction-free DOM manipulation code rather than having a complex virtual DOM reconciliation or data-binding process. > rather than a new beautiful finished paradigm Nowhere does it claim to be finished. If anything, it's the start of a new approach to building UIs.
- matchu 10y ago

ricardobeat 10y ago

Has anyone done further testing on the growth rate of the compiled code for larger projects? From the discussion when this launched it seems like the difference will be mostly felt by smaller apps. That aside, being able to write 'universal' components that work independently of a framework is still a great thing to have.

rich_harris 10y ago
Since launch we've added the ability to generate code that reuses functions between components. If you use the CLI it will create 'standalone' modules, but if you use something like https://github.com/rollup/rollup-plugin-svelte https://github.com/rollup/rollup-plugin-svelte then code will automatically be reused.

aaronfc 10y ago

Whenever and wherever I read "rock solid" I stop reading... I hate that expression so much!

aarpmcgee 10y ago
Why?
- the_duke 10y ago
  I agree. Whenever I read 'rock-solid' my distrust alarm goes off and it's almost always reading some buzzword laden marketing text.
- Nekorosu 10y ago
  Because it expresses the authors confidence but doesn't give anything informative. Show me metrics, features, idioms and working examples.
  - proyb2 10y ago
    Meanwhile, you can download and try the sample code. https://github.com/sveltejs https://github.com/sveltejs I spent a few days testing and it was an eye opener, compare to the numbers of >100 outstanding issues filed in React, Angular, etc which may probably never fix it for some reason and complexity.
    - tracker1 10y ago
      Something tells me, should svelt get to the number of stars that React and Angular have, you'll see a similar number of issues.
      - proyb2 10y ago
        We need a robust testing system to reduce bugs, improve performance and do some recommendation where code quality can be simplify or better security. I believe not many community can affordable the time to write testing, even expertise skived and problem appear at compile time.

gigatexal 10y ago

How does anyone even begin to start learning how to make Web 2.0 webpages with a new JS framework every week?

greyskull 10y ago
If you can't afford to be on the cutting-edge, you use battle-tested technologies, and let the people who can afford it do their thing to shake out which products are worth keeping around. That's sort of the right approach for any software development, yeah?
- innocentoldguy 10y ago
  Yeah, but most other technologies don't have new libraries and frameworks coming out every other day. For example, with Ruby, the community has stuck with Rails and Sinatra for more than a decade now. With Python, most developers go with Django or Flask. With Elixir, Phoenix or Plug. With Javascript/Node, however, you have Hapi.js, Sails.js, Mean.js, Koa, Socket.io, Mojito, Express.js, Meteor, Mithril.js, Derby, and others, not to mention the front-end options, like Angular, React, Svelte, etc., Some of these frameworks are even written by the same developers to accomplish largely the same thing (e.g. Express vs. Koa). This doesn't seem like a great strategy for long-term success. It got to the point with me that I didn't want to invest any more time in Javascript technologies, simply because their lifespans seemed to be quite short, compared to other options. In the Javascript community, framework feel disposable. I don't mind learning, but there has to be time for implementation and mastery, and there has to be some level of long-term career payoff for the time invested in learning. For example, I can still get any number of Rails jobs after 11 or 12 years of using the framework. Can the same be said of the original Express.js? I know it isn't a comprehensive, scientific study, but a quick search on local job boards in my area turns up 15 Rails jobs, and no Express.js jobs. No Hapi.js jobs. No Metor jobs. No Mithril.js jobs. No Derby jobs. I don't mean to take away from the successes the Javascript community has had over the years. Javascript is certainly in a better state than it was a decade ago. However, having so many libraries and frameworks come and go so quickly isn't a good thing, in my opinion. I think the community could benefit a lot by embracing more cohesion and focus, but that's just my opinion, based on my experience with other languages and communities.

revelation 10y ago

Code generation, the frontend craze must have arrived at the Java enterprise deadends. Time to mount the JET emitters and blast out that code.

laughingman2 10y ago

I think with advent of Inferno, 9KB for a view layer runtime, which has overhead of just 4% above vanilla JS is acceptable for me to compiled view layer that repeats code everywhere.

soperj 10y ago

It's funny that everyone on here is pretty critical of this. To the maker, don't pay any attention, your users will give you much better feedback.

rich_harris 10y ago
Thanks! Don't worry, this ain't my first rodeo :-D Just glad for the opportunity to help clear up any misconceptions people have, it's always useful to get feedback about how we can better communicate the ideas.

simplify 10y ago

How does this compare with Marko.js, which also compiles (and renders!) JavaScript on the server before sending to the client?

kensign 10y ago

I think http://aurelia.io http://aurelia.io is much cleaner.

proyb2 10y ago
Cleaner as in? Aurelia is on the same idea as Angular 1 by the same inventor.

fenollp 10y ago

So the core idea is similar to https://github.com/purifycss/purifycss https://github.com/purifycss/purifycss but for JS code. Then why does Svelte wants to be yet another framework? Do a real good one to the world and be something that you can plug into Gulp or a Makefile...

rich_harris 10y ago
Not really similar at all. It's a compiler, not just a code removal tool. > Do a real good one to the world and be something that you can plug into Gulp or a Makefile... You can easily use Svelte in Gulp tasks or Makefiles. Maybe do a tiny amount of research before criticizing something. God the HN crowd is tedious sometimes
- arxpoetica 10y ago
  Ha!

nkkollaw 10y ago

Can I say something shallow? I talked to a couple of programmers about the project, and they laughed at me because of the name, dismissing the project and not even wanting to hear about it. Everyone keeps saying that the name is not important, citing examples like Yahoo, Google etc., but it is. I was reading about how execs didn't want to replace Android with Cyogenmod, and I bet part of the reason is the name. It's hard to pronounce, it contains "mod" in it, and it sounds like a tool for hackers instead of a reputable operating system that corporate would be ok having on all their phones. "Svelte" sounds like a name for a dish washer brand.

rich_harris 10y ago
'Svelte' means 'slender and elegant', 'urbane', 'attractively thin, graceful, and stylish', or 'lithe', depending on which dictionary you consult. It comes from the Italian svelto meaning 'quick'. Those are all excellent connotations! But yes, it seems that a lot of people, at least here in the US, aren't familiar with the word. It doesn't matter though. I build tools for my job because the existing ones don't meet my needs, and then I share them because there's no good reason not to. I couldn't care less whether or not people use them as long as the ideas get out there. So if someone decides not to use Svelte because they don't like the name, all I do is shrug.
- halfdan 10y ago
  They should probably release an americanized version called "swell" - http://www.urbandictionary.com/define.php?term=swell http://www.urbandictionary.com/define.php?term=swell
- nkkollaw 10y ago
  I'm from Italy and so were 2 of my programmer friends. We're used to English, though. The other guy is from Sweden. I wonder if it sounds better to people whose first language is English. It doesn't seem like you care (I guess rightfully), just a note.
coldtea 10y ago
>I talked to a couple of programmers about the project, and they laughed at me because of the name, dismissing the project and not even wanting to hear about it. Clearly a sign that you should avoid listening to said programmers on any important matter from now on, because they are 16-year olds inside (not to mention they haven't even bothered to open a dictionary in their lives). Reminds me of people that laughed at iPad's name (because of the maxi-pad connotations).

bastijn 10y ago

"In Svelte, an application is composed from one or more components. A component is a reusable self-contained block of code that encapsulates markup, styles and behaviours that belong together." So, the idea is to be kind of like Web components? Even after reading the comments in this thread and the website it is hard for me to grasp where Svelte's place is. Is it for people who need the performance without giving up the work flows of the regular frameworks they are so used to? If it is for encapsulation I would say webcomponents is the better choice here? Although you could argue Web components isn't ready yet either for the big masses.

rich_harris 10y ago
Very much like web components, except a) they work everywhere without polyfills, and b) they're nicer to build, because they have a friendlier API and templates are more declarative (with web components you still have to do a lot of grubby manual DOM manipulation) and you don't have to learn a bunch of confusing new shadow DOM stuff just to encapsulate styles. Also, with Svelte you can do server-side rendering, which is a bit of an oxymoron with web components.
- bastijn 10y ago
  a) is a bit of a weak argument as polyfills are a temporary solution until browser support is available everywhere. Also, Web components are (indirectly) part of the W3C spec so browser support will follow. B) OK. Though subjective. C) Active support for this is a nice thing to have. Guess it ain't enough for me to use hut I see its use for others. Still, YAJF as far as I'm concerned.
  - rich_harris 10y ago
    > polyfills are a temporary solution until browser support is available everywhere Well, you might be waiting a while! Web components are actually four separate specs. While templates are widely supported, the future for custom elements, shadow DOM and HTML imports is less clear (well it's very clear for HTML imports — it ain't gonna happen). Edge is 'considering' whether to implement shadow DOM and custom elements, Firefox says they're 'in development' but from the outside it looks like that development has stalled. Even if web components had major advantages that outweighed their disadvantages, personally I'd be very hesitant to use them until browser vendors make their intent to support them much clearer.