
Svelte – A UI framework that compiles into tiny standalone JavaScript modules - bpierre
https://svelte.technology/blog/frameworks-without-the-framework/
======
skrebbel
Love it. I think the most discussion-worthy quote I found in the docs is this:

> _It 's currently fashionable to avoid two-way binding on the grounds that it
> creates all sorts of hard-to-debug problems and slows your application down,
> and that a one-way top-down data flow is 'easier to reason about'. This is
> in fact high grade nonsense. It's true that two-way binding done badly has
> all sorts of issues, and that very large apps benefit from the discipline of
> a not permitting deeply nested components to muck about with state that
> might affect distant parts of the app. But when used correctly, two-way
> binding simplifies things greatly._

I wonder what the author considers "used correctly" and "done badly" and how
Svelte approaches this.

~~~
jerf
My understanding is that there are two issues with two-way binding that are
structural, and will be difficult to fix no matter how you approach it.

First is that if you look at the system as a graph of updates, automatically
closing all cycles between variable update and widget means that any
additional two-way binding links you add become a cycle, which makes it
difficult to implement, model, and debug. If the framework only initially
links the variable to the widget or the widget to the variable, the graph is a
lot less populated to start with and creating a cycle is much harder.

Second is that the developer ends up wanting more and more complicated
transforms over time, and having to implement both directions of them at once
is much more difficult than having to implement only one direction, because
not only are you writing two transforms instead of one, you _also_ really
ought to make sure the transforms are able to be roundtripped without data
loss, and also that any invalid states on either side of the transform are
handled sanely in some manner. Very few developers think this way; it's one of
those places in programming where you really need to approach it with a
mathematical state of mind, but it's generally being written by the "I don't
see how programming is connected to math" types. (Which is something a two-way
binding advocate needs to keep in mind when writing their library; you're not
going to get your users to deeply understand the way the library works before
they can benefit from it, they're going to want to just dive in and get
something useful going.)

These are not necessarily insurmountable problems, but they are _fundamental_
problems to having two-way binding. I think these two things are why it has
never really taken off despite the fact I've seen at least half-a-dozen
attempts over the years. I can imagine programming language tools that could
help with both problems, but as what I'm seeing getting sketched up in my head
requires a type system at least as strong as Haskell's to be practically
usable without so many holes as to be insignificantly different from what we
already have, it's not going to take off anytime soon.

~~~
erydo
This is a really helpful way of describing the problem. Concretely describing
behavioural coupling in terms of graphs is much less hand-wavy than the
normal, "things become tightly coupled and which becomes hard to deal with."

~~~
Marazan
That's the core of it - 2 way data binding creates tight coupling.

------
mambodog
TodoMVC is a useless benchmark for the problem that this claims to be
addressing. The limits we're hitting with our applications now are with BIG
applications, with many routes, many views, and lots of client side logic.
We're talking hundreds of files (in some cases, thousands). Of course a
framework, with it's fixed overhead, is going have a bigger payload for a tiny
demo app like TodoMVC, than something like this which compiles to some amount
of overhead which grows seemingly linearly with application size.

That said, I'm not criticizing the framework here, and I welcome new ideas,
but a better choice of benchmark is sorely needed to be persuasive here.

~~~
straws
Are there any alternatives to TodoMVC out in the wild?

I rather like [https://github.com/staltz/flux-
challenge](https://github.com/staltz/flux-challenge) myself, but I wonder if
there are any other projects that are focused on more complex examples.

~~~
kgr
The 7-GUIs suite looks better, but so far only one JS framework implements it.
The problem with more realistic benchmark apps (or suites) is that they
require more effort to implement, so you have a selection bias towards easy-
to-implement yet too-small-to-be-useful demonstrations like TodoMVC.

Something like a GmailMVC would be better.

[https://github.com/eugenkiss/7guis/wiki](https://github.com/eugenkiss/7guis/wiki)

------
blauditore
> You can't write serious applications in vanilla JavaScript without hitting a
> complexity wall.

This somewhat annoys me. You _can_ definitely do it.

Sure, it's easier, more comfortable, safer and quicker to use something like
React. But you can still do some modularization that scales reasonably well
without it.

I've been working on an app and spent a lot of time looking into frameworks to
handle its complexity but ended up sticking to vanilla JS to keep more
control, especially for detail optimizations.

~~~
boubiyeah
You can if everyone in the team is at least pretty good

~~~
bryanrasmussen
'pretty good' sounds like a doable metric for a small team.

------
dotancohen
This looks nice: a Javascript framework for expressing _concepts_ that
compiles down to vanilla JS. It looks like it ships a lot less code to the
user. From the project's first [blog
post]([https://svelte.technology/blog/frameworks-without-the-
framew...](https://svelte.technology/blog/frameworks-without-the-framework/)):

> The Svelte implementation of TodoMVC weighs 3.6kb zipped. For comparison,
> React plus ReactDOM without any app code weighs about 45kb zipped. It takes
> about 10x as long for the browser just to evaluate React as it does for
> Svelte to be up and running with an interactive TodoMVC.

~~~
danmaz74
I didn't study the thing, but the first question that comes to my mind is: if
each component is rendered as a self contained piece of vanilla js, isn't the
size of an app with lots of components going to increase much faster than with
the library approach?

A complete library by itself can be pretty big, but it stays the same size no
matter how many components you add.

~~~
callumlocke
Good point. I tested the demos and found the output (compiled down to ES5 and
minified) is around 2-3KB for the minimal demos, and 9KB for the complex SVG
clock demo.

The equivalent JSX output for that clock demo is about 1KB. So yes, I would
guess that apps with many components would end up bigger (in total JS bundle
size) than equivalent React apps.

Possible counterarguments:

\- Bundling and gzipping several Svelte components together might compress
well – a lot of their size comes from repetitive substrings like
`.parentNode.removeChild` and `.setAttribute` etc.

\- Once downloaded, the Svelte approach would probably be faster than React
(at both rendering and updating) and would use less memory (no virtual DOM, no
diffing, just fast granular updates).

\- The self-contained nature of Svelte components makes it easier to treat
them as atomic downloads and use them as needed. For example, you could get to
a working UI extremely fast, and then download more components for below-the-
fold or other pages in the background. This could work well with HTTP/2.

~~~
nojvek
Storing state in Dom and reading from it could be dangerous. It's very easy to
force layouts when you don't need. Frameworks like react and preact
essentially do this. Abstract updating the view in a performant manner. Preact
is 3kb. Magnitudes smaller than React.

~~~
callumlocke
I don't think it stores state on the DOM and reads from it. Pretty sure it
just stores state in an object, and it updates the DOM granularly when that
state changes. (That said, I did notice a bit of DOM traversal
(node.parentNode...), which doesn't count as reading state from the DOM, but
does rely on the structure of the DOM not having been altered by someone else
since the last render – not sure why it needs to do this.)

------
crudbug
Love the ideas.

I think now the community has settled on the Component based development,
especially with JSX templates.

What we need are multiple _react-kernels_ implementations. I see React
community providing component API specs. Similar to Linux distros, we should
have API compatible implementations, where application code can run on
multiple kernels without any changes. We are now seeing multiple react-shim
layer implementation - Preact [0], Inferno [1].

[0] [https://preactjs.com](https://preactjs.com)

[1] [https://github.com/trueadm/inferno](https://github.com/trueadm/inferno)

~~~
ranyefet
Totally agree. I just can't see myself going back to templates with special
DSL. I rather just use JS :)

------
fzaninotto
The precompilation is a nice idea, but I'm not buying the "vanilla JS"
argument. The reason why React and other frameworks have a runtime is also
because they optimize rendering.

The Svelte doc says: every call to `component.set()` produces a synchronous
DOM update. I can already see how this leads to very poor rendering
performance in applications with a large number of nested components.

React and the Virtual DOM solved this problem, and that's why web apps today
use a lot of components. So until Svelte can demonstrate fitness and speed
comparable to React on large apps, it just looks like Yet Another JS
Framework.

~~~
mvindahl
Haven't studied the SvelteJS documentation but as far as I can reason there is
nothing in their idea that prevents them from shielding the DOM behind a
lightweight, virtual DOM, ReactJS style. In fact, I'd be slightly disappointed
if they don't shield the DOM somehow. It's the #1 bottleneck, after all.

~~~
JDDunn9
The virtual DOM isn't a replacement for the DOM, it's just a string diffing
algorithm. It is only needed because of React's "render everywhere" approach,
which is a tradeoff sacrificing efficiency for simplicity. If you don't re-
render the entire page any time the model changes, you don't need a virtual
DOM.

~~~
mercer
I'd say your mostly right with the one caveat that a virtual DOM also helps
out with batching changes to the DOM, but I suppose there are other ways to
make that happen.

------
throwaway13337
[https://svelte.technology/guide](https://svelte.technology/guide)

For how it actually looks.

Interestingly, it shares most similarities to vue. I guess vue is winning
mindshare.

~~~
rich_harris
It's based heavily on Ractive ([http://ractivejs.org](http://ractivejs.org)),
which Vue is very similar to.

~~~
spiffytech
Should users evaluate both Svelt and Ractive, or should Ractive be considered
deprecated in favor of Svelte?

------
bryanlarsen
Precompilation is cool, but please don't imply that your framework is the
first to do it. Precompiled templates significantly predate HTML, they were
common in the mainframe world. In the HTML world there are tons of other
templaters that allow precompilation. Handlebars is a common one:
[http://handlebarsjs.com/precompilation.html](http://handlebarsjs.com/precompilation.html)

This is a huge part of Javascript fatigue for me. I love the fact that we're
recycling old concepts and mashing them up to get constant improvements and
better tooling. It's the relentless hype and pretending that everything is new
that really gets to me.

~~~
callumlocke
Handlebars templates have a runtime dependency (even when precompiled). Svelte
does not.

Also, a precompiled Handlebars template is just a function for outputting an
HTML string (with a runtime dependency). By comparison, the compiled Svelte
output is a dependency-free JavaScript module for a dynamic view, which knows
how (and when) to granularly update the browser DOM in response to state
changes. It's unprecedented.

Check out the output from this SVG Clock demo:
[https://svelte.technology/repl/?gist=44e20b4e0224617d228e3c3...](https://svelte.technology/repl/?gist=44e20b4e0224617d228e3c38c119ee76)

~~~
bryanlarsen
Svelte has a runtime dependency too, it's just bundled into the output.
Everytime I've used handlebars I've bundled the runtime into my final
application file. But I do it myself so it only gets bundled once rather than
N times like it would be for svelte.

~~~
ricardobeat
See the `update` method in the output of the Hello World example:

    
    
        update () {
            text1.data = root.name
        }
    

This is _the entire DOM manipulation code for this component_.

There is no runtime library. The trick here is that the generated code is
aware of exactly _what_ DOM updates are needed. Instead of a large, general-
purpose reconciliator like React's, you have specialized code for changing the
DOM, generated from your templates.

------
amelius
> It's basically as fast as vanilla JS, which makes sense because it is
> vanilla JS – just vanilla JS that you didn't have to write.

What kind of logic are they using here? Isn't any javascript just vanilla JS?

~~~
1_player
The way I see it is Svelte treating the browser JS implementation as "machine
code": while frameworks such as React or Vue are by definition a (runtime)
layer on top of vanilla JS, Svelte _compiles_ your code to vanilla JS.

It's a very slight but interesting distinction.

------
catshirt
React fanboy chiming in to say... an interesting approach to what is probably
a problem.

i wonder, though, if compilation is really better than creating a library? if
we look at the REPL output [0], we can see what comprises the bones of a
Svelte component, and how much generated code will be replicated.

it also shows that the more interesting part here is it's method for
rendering. it's use of data binding and compilation means we don't really need
something like VDOM to stay efficient (at least, not a VDOM running in the
browser).

[0]
[https://svelte.technology/repl/?gist=0ed5146aa22c28410dfcff2...](https://svelte.technology/repl/?gist=0ed5146aa22c28410dfcff2050f3d2f8)

------
hbbio
Why didn't we think of this sooner?

Because we did! For instance, this is exactly the approach that we have
released back in 2009 with [http://opalang.org](http://opalang.org)

Naturally, there are things we would implement differently today, but the
OCaml codebase of the compiler is still, in my humble and biased opinion,
pretty valid.

~~~
zem
is opa still alive and being used? i was pretty excited about it when it was
released (especially when it still had the ML syntax), but it never seemed to
gain any traction.

~~~
hbbio
Thanks zem! Yes, Opa is still used in several projects and pretty stable. But
the project is asleep and not very active as of now.

------
ChemicalScum
I like how they solved scoped css. Looks way more elegant than most css-in-js
solutions I've seen. I could give it a shot for this reason alone.

~~~
toddmorey
Always one of my favorite features of riotjs

------
spraak
The 'Mustaches' bit killed it for me, but up until then I was enjoying the
simplicity of the API. I like React (and React-like implementations) because
of being able to use JS to build up a view

~~~
boubiyeah
Yeah, same. Can't give up JS/TS templating and typesafety. simply for a
smaller size, I already use something that is way, way smaller than react.

~~~
spraak
I'm curious, what do you use?

~~~
boubiyeah
In the past, I used virtual-dom. It works fine, but it's discontinued and
doesn't address the problem of encapsulated component state. Now using this:
[https://github.com/AlexGalays/kaiju/](https://github.com/AlexGalays/kaiju/)

------
eob
Looks neat, but also like a non-standard implementation of Web Components,
which, though slow coming, already have universal browser support with a small
shim.

What's the advantage of this over something like Google's Polymer library,
which is a toolkit for rapidly creating reactive web components?

~~~
boubiyeah
Polymer is an enormous library.

~~~
eob
Polymer offers a lot of UI widgets, which are enormous when you glob them
together, but the base polymer library is actually incredibly small due to the
fact that's it's leveraging the browser's native custom element functionality.

Can't reply to your comment so editing here:

Works natively on IE11+, Edge, Safari 9+, Chrome, Opera, Firefox, and mobile
browsers. The polyfill for everyone else (webcomponents-lite.js) is 41kb.

~~~
boubiyeah
Ok, it has been some time since I checked. Don't you need lots of big
polyfills ?

~~~
ergo14
No - 95% of time you need that webcomponents-lite to get things working.

------
pwr
Isn't the problem of including only the code the component actually needs
already solved with dead code elimination? So the framework authors can
include new features but as long as your component doesn't use them the code
for those feature does not end up in the final bundle you serve to the user.

I sure am missing something here because the author of Svelte is actually also
the author of rollup.js [1] which does exactly that, it eliminates dead code
via its tree-shaking mechanism.

[1]: [http://rollupjs.org](http://rollupjs.org)

~~~
mvindahl
As far as I understand, ReactJS is a tightly weaved 40kB chunk of code which
will be delivered to the browser no matter how ferociously you shake the tree.

------
SEJeff
Pretty neat demo of Svelte for the home assistant project:

[https://twitter.com/balloob/status/803882259719696384](https://twitter.com/balloob/status/803882259719696384)

And the actual code:

[https://github.com/balloob/home-assistant-svelte-
prototype](https://github.com/balloob/home-assistant-svelte-prototype)

------
the_duke
Vue.js has single file components [1] and template precompilation [2] (or
optionally JSX support, which is basically a precompiled template).

I don't see the point of yet another framework here.

The "no dependencies" argument seems to fall down for me, since it would seem
to me that they would need to duplicate a lot of code for state management and
rendering, bloating the code for anything more complex.

And if there's some clever tree shaking or whatever going on, than I don't see
the point as opposed to just including another JS file...

I couldn't find any explanation of what's so different here, worthy of
creating another framework for it. Would love to be enlightened!

[1] [https://vuejs.org/v2/guide/single-file-
components.html](https://vuejs.org/v2/guide/single-file-components.html)

[2] [https://www.npmjs.com/package/vue-template-
compiler](https://www.npmjs.com/package/vue-template-compiler)

~~~
rich_harris
As well as generating smaller apps and being quicker to load, Svelte is
significantly faster than Vue. We'll be publishing benchmarks soon.

~~~
the_duke
I'd love to see code size and performance comparison for a relatively simple
but non trivial component, like a DateTime picker.

~~~
rich_harris
Yep, we'll be adding more examples soon – definitely on the TODO list. In the
meantime you can take a look at our TodoMVC implementation – it's 3.6kb zipped
(Vue is 17.2kb without any app code. Not a criticism, just context)

[https://svelte-todomvc.surge.sh](https://svelte-todomvc.surge.sh)

------
mwcampbell
I like the idea of abstractions that exist only in the source code and at
compile time, and have zero runtime footprint.

How does this compare to Google's Closure compiler and library? Does Svelte's
compiler do anything that the Closure compiler cannot? Or how about running
the source through a hygienic macro system like sweet.js and feeding the
output of that to the Closure compiler?

I ask because I'm skeptical of a new, unproven compiler. Google has been using
the Closure compiler on production code for years, and its optimizations are
pretty awesome.

~~~
boubiyeah
But the google closure compiler have no concept of a tree of components and
their lifecycle. The library is old, java-like and I never heard about someone
using it :p

~~~
camwest
Don't quote me on this but I'm pretty sure gmail uses it. I'd say that's a
pretty big endorsement.

~~~
fnordsensei
From what I've read, also Docs/Drive and Maps.

It IS old (well, 2009 counts as old I guess), but it's still maintained, and
still doing what it says on the tin. That's quite an achievement in and of
itself.

~~~
camwest
Yeah I think I read it here:
[http://shop.oreilly.com/product/0636920001416.do](http://shop.oreilly.com/product/0636920001416.do)

------
goliatone
This looks interesting. For the past 3 years I've been using ractivejs and
really enjoy it.

I'm wondering if Svelte will take away development efforts from ractivejs?

OT >The web's obesity crisis, solved. Svelte turns your templates into tiny,
framework-less vanilla JavaScript.

Made me think of [idlewords][1] website obesity presentation...

[1]:[http://idlewords.com/talks/website_obesity.htm](http://idlewords.com/talks/website_obesity.htm)

~~~
draw_down
I think Rollup already took time away from Ractive. It's really too bad, I
think Ractive has some great ideas and I really enjoyed working with it. It
was the best way to build web UIs I've come across. But I feel its future is
uncertain so it's hard to recommend others begin using it.

~~~
TeMPOraL
> _I feel its future is uncertain so it 's hard to recommend others begin
> using it._

Self-fulfilling prophecy unfortunately.

~~~
draw_down
Perhaps, but at least to the team I was working with at the time, Rollup
indicated we shouldn't expect much to change or improve in Ractive. I think
Ractive was partially a victim of timing; as Harris himself has said, it has
many of the same ideas as React and he may well not have made it if React
existed when he began. And it never really seemed to gain much popularity
which you kind of need for a project to grow beyond just its creator. I still
haven't investigated this new thing, but if it was indeed inspired by Ractive
that gives me hope.

~~~
goliatone
>but if it was indeed inspired by Ractive that gives me hope

Actually, I would like to see the author's thoughts on ractive vs svelte. From
the outside svelte is very reminiscent of ractive.

[EDIT] +\n

------
adakbar
Out of topic, is low contrast and small fonts become a thing? I can barely
read anything from my 13-inch notebook with 45cm distance between my eyes.

------
psion
Why are there complex MVC frameworks that run in the browser in the first
place? I might get some flack for this, and I'm prepared for it, but why can't
we use JS as just a view manipulator? Leave data processing and business logic
to the back-end, on the server, and that can take care of needing a front-end
framework and large app.

~~~
fredley
"Why waste energy doing stuff on your machines what you can get your users to
do for you?"

...is the general reasoning. However, personally, I find that unless you're
_very_ well organised, you're not saving yourself much, if anything, in the
long run.

~~~
michaelmcmillan
That reasoning quickly falls apart when you throw a cache in front of your
backend.

------
ergo14
Why would I use this vs established and polished project like Polymer that
already has a big ecosystem of components for reuse?

~~~
untog
If that's your requirement, you wouldn't. But every project has to start
somewhere.

------
wiradikusuma
So this is like GWT, minus Java? GWT's treeshaker removes dead code and
outputs fat-free plain JS.

~~~
boubiyeah
GWT was backend oriented and sucked at delivering a nice UX in a decent
timeframe. So it's actually extremely different. You could compare this to
vue, ractive + a strong compilation step.

------
the_jp
So apparently Svelte JS framework already exists. So many frameworks, you need
to start asking which one.. :)

[https://github.com/mattbegent/svelte](https://github.com/mattbegent/svelte)

------
dodyg
Rich Harris created RactiveJs, which is an awesome UI framework on its own
right.

~~~
theasker
Rich Harris also created rollup and buble.

He's an inventing and implementing machine.

------
sapeien
This looks a lot like another JS library that was posted here previously:
[http://monkberry.js.org/](http://monkberry.js.org/)

Both compile templates to DOM manipulation code.

------
laurent123456
That seems quite amazing, especially the todo example being over 10 times
smaller than the React one. Are there any drawbacks to this approach?

~~~
boubiyeah
To be fair, there are today numerous frameworks that are 10 times smaller than
react and can do roughly the same things.

Drawbacks would be maturity, community size, template closed expresiveness and
not typescript friendly. Nothing too major.

------
max_
Mores like Sass for JS. exactly what we need!

------
tycho01
This compiler sounds similar to me as the Ahead-of-Time (AoT) compiler
currently shipped in Angular 2.

------
kimshibal
We move React to Svelte at work. We saw a huge file size decrease. almost 50%.

~~~
canyonero
Why exactly did you choose to move to a framework that, according to it's
commit history, had its first commit 15 days ago?

Why are people porting apps to a framework that is a few days old?

I find it very difficult to believe that your app, with it's 50% size
decrease, has any more complexity than a todo app.

Just, why?

~~~
kimshibal
We want cleaner approach in writing code. We like inferno and riot, but we
choose Svelte. Results have been amazing.

~~~
blueprint
When did you find out about the framework? How did you find out about it?

------
constantlm
This looks like a very stripped down Ember.js - it also looks pretty awesome.

------
danesparza
Where is this being used right now in production?

~~~
victorvation
Likely nowhere yet, seeing as Svelte is four days old (give or take a few
hours).

------
devdoomari
how about porting this to scalaJS? would be awesome to use scala's
typechecking on this (especially on template strings)

------
thomasstephn
[http://dayssincelastjavascriptframework.com/](http://dayssincelastjavascriptframework.com/)

~~~
ialex
does it ever goes higher than 0?

------
ng12
How is this substantially different from Backbone/Marionette? I feel like
we're regressing.

~~~
boubiyeah
Because it has data binding.

You only write your template once, you don't have to think about two separate
paths: creation and update. With backbone, you either did that and had
performance issues or did updates separately, which is a pain to maintain.

Also, in backbone, parent<->child communication is a complete after thought.

------
uvesten
Is it possible to filter out all JS/Framework stuff from the hn feed?

Asking for a friend.

~~~
crazysim
Write a some JS for a userscript?

------
Retr0spectrum
Are there any apps currently made with this?

------
minxomat
A side note about that website. Thin and Extra-Thin fonts have no place in web
design (there are some exceptions in huge title text). They are an unnecessary
burden for people with limited eyesight and elderly people[1]. Even for me, on
my 1366x768 screen (which is still the single most common resolution for cheap
notebooks, dear HiDPI web designers[2]), the bullet text is hardly readable,
the copyright line is completely unreadable. This effect is made even worse by
choosing inadequate contrasts[3]. One can use subtle colors for increased
contrast.[4]

[1] [http://www.aiga.org/typography-and-the-aging-
eye](http://www.aiga.org/typography-and-the-aging-eye)

[2] [http://blog.typekit.com/2013/05/01/hi-dpi-
typography/](http://blog.typekit.com/2013/05/01/hi-dpi-typography/)

[3] [https://www.nngroup.com/articles/low-
contrast/](https://www.nngroup.com/articles/low-contrast/)

[4] [https://www.viget.com/articles/color-
contrast](https://www.viget.com/articles/color-contrast)

~~~
kowdermeister
Create an issue here:
[https://github.com/sveltejs/svelte.technology](https://github.com/sveltejs/svelte.technology)

or submit a pull request

~~~
hood_syntax
Not sure why you were downvoted, I think it's entirely reasonable to bring up
his concerns in an issue regardless of whether they are eventually
implemented.

------
nkkollaw
I love the ideas.

The only other thing I like is CSS scoping, though. I think that CSS scoping
is a problem in React, and current ideas on how to implement that in React are
absolutely horrible IMHO.

Two-way binding is a step back I think, I don't love the name (lots of people
will judge a new technology by its name), and the thought of introducing yet
another framework is a nightmare.

I'd personally go with Polymer if you like scoped CSS, since it's already
established and it's a good project.

I wonder if these ideas can be somehow applied to React, doing precompiling on
React components, so that one can continue taking advantage of all freely
available React components out there, and keep using Redux.

~~~
rich_harris
> Two-way binding is a step back I think

You don't have to use it – its effects are restricted to the subtree where
you've explicitly opted in to it. I've personally found it to be a huge
timesaver, and would never go back to a world where I didn't have the option
of using it. But you're in no way forced into it.

> I wonder if these ideas can be somehow applied to React

A lot of people have wondered that, including me. Unfortunately, a compiler
wouldn't be able to generate a good picture of the _structure_ of a JSX
component – because it's 'just JS' it resists the kind of meaningful static
analysis that Svelte can take advantage of. I'd love to be proven wrong, but
sadly I just don't think any JSX-based framework will ever be able to fully
embrace these techniques.

~~~
nkkollaw
Got it. I've been reading the guide, it looks good.

You did an awesome job.

I'm really scared about trying out yet another framework since I've tried
pretty much all of them before settling on React, (and I guess a lot of people
will be, too, since there's a new one every couple of months) but I'll try
this weekend.

Thanks!

------
brilliantcode
So I've just wrapped up using React + Redux and just begun to uneasily accept
JSX.

It makes me uneasy because React wraps up existing HTML with Javascript.
Because it violates using existing, established standards that have truly
stood the test of time and wasn't broken at all.

Svelte really hits that sweet spot.

~~~
spion
I believe most of the brokenness of current day frameworks comes from
templates. Here is what you get by JSX being JavaScript:

1\. Easy to write typechecking for the templates.

The compiled template is just function calls (or well, factory function calls)
and the typechecker can work with that.

How many template language authors will write a typechecker for the template
language?

2\. Sane scope sharing - you can take advantage of all existing encapsulation
and modularization tools of JavaScript. How do I expose functions to JSX? I
simply bring them in scope e.g. by importing them or defining them. How do I
expose functions to the template? Well... it depends. There is this $scope
object (Angular)... Or there is this components property which informs the
template whats in scope (Vue:
[https://vuejs.org/v2/guide/components.html#Local-
Registratio...](https://vuejs.org/v2/guide/components.html#Local-
Registration)). I guess there are worse options, like having to register your
helper functions or components into some sort of global registry and pray that
there wont be a conflict.

3\. First class components - want to write a list component that takes an item
component as a parameter in props? Tough luck, its likely that the template
language of your average framework doesn't support this. JSX gets this for
free because its just JavaScript, and JavaScript is a proper language with
first-class support for passing around functions and classes.

Its not that its impossible to do this... its just that most template
languages aren't advanced enough, and somehow we think thats a good thing.

4\. The sandboxing fallacy

From
[https://angularjs.blogspot.co.uk/2016/09/angular-16-expressi...](https://angularjs.blogspot.co.uk/2016/09/angular-16-expression-
sandbox-removal.html)

    
    
      Angular template, and expressions, should be treated
      similarly to code and user-provided input should not be
      used to generate templates, or expressions
    

If you are distributing the compiler with your framework, there is this urge
to expose it to the developers. If you expose it to the developers, there is
the chance that it will end up compiling user input. And then you spend
ungodly amount of time building a sandbox, unsuccessfully.

-

svelte seems to be built by people with deep interest and expertise in
compilers, so I'm somewhat hopeful that its template language will not suffer
from the usual template language problems. On the other hand, the task is much
harder (compiling to code without runtime), so that seems like a driving force
in the opposite direction (less powerful template language). I guess we'll see
how it goes.

IMHO the next step in frameworks isn't this (compilers are hammers, and
everything else is nails). The next step is, after current frameworks fight
things out, we take the common subset of the "infrastructure code" that the
most popular ones use (DOM diffing? events that are the same across browsers
to remove the need for synthetic events? PropTypes? Maybe someone at whatwg
should start thinking about this list) and include it in the browser API, then
let frameworks build on top of that and be 10 times smaller on average.

~~~
brilliantcode
Thank you for the detailed answer, I have a few questions here but I think
you've nailed it for the most part, I'm just trying to gauge how well I
understood what you wrote.

1) what is meant by type checking in this context? do you mean that now that
HTML is converted to JSX in JS context, you can test HTML as if they were
Javascript Objects?

2) so the ease of importing functions to JSX + use of existing "encapsulation
and modularization" (I'm not sure what this menas) libraries.

3) what makes it difficult to support it from templates point of view? JSX is
easier because?

4) why is sandboxing harmful? how does giving developers compilers create
sandbox fallacy?

With the last paragraph, you are saying that the lowest common denominators
such as DOM diffing will become a common cross platform feature in all
browsers?

~~~
spion
By type checking I mean something like typescript which is able to statically
verify whether the right types of attributes are passed to the right
component, or whether expressions embedded in the template are of the right
type.

Re encapsulation, the way that JS provides it is scope. JavaScript's lexical
scope ensures that things you define in a function are only visible in that
function, or that things you define in an ES6 module are only visible in that
module. Even with the tiny quirks of function based lexical scope, its natural
and intuitive: if you can see the definition (or import) in the
(function/module) parent(s) of the code you're looking at, its available. Its
a tried and true solution.

Template languages don't always bother to add something like "import" or the
concept of lexical scope, so when you want to share something from JS (or
other templates) with them (like data, or processing functions, or components)
you need to somehow put it in their own custom scope. Many template based
frameworks make the mistake of working around this not by adding import
mechanisms to the template language, but by registering things globally - e.g.
when you register a component in Angular or Vue it becomes globally available.
This has the same problem any other global variables have. (I suspect this in
Angular 1 is what led to the totally parallel "module system" with dependency
injection, although maybe they just didn't like the existing ones)

Regarding supporting first class components in template languages, its not
really that difficult. Its just that we believe the fallacy that we need the
template language to be underpowered. Also, once you add support for first
class components and JS scope sharing (or at least import/export) mechanisms
to a template language, you've basically reinvented JSX (perhaps with a
different syntax)

Sandboxing isn't harmful, its just extremely hard. Angular spent years trying
to write a proper expression sandbox and every new version of it was broken
successfully - thats why 1.6 removed the sandbox.

What I'm hoping for is that someone works out what contributes the most to
popular framework's size, takes the common parts and provides them as built in
API in the browser in such a way that the frameworks can take advantage of
that instead of writing their own implementations.

------
jlebrech
i wonder if it would be faster if it compiled all the html down into a kitchen
sink file.

does it try and do as much as it can without javascript?

------
nilved
> You can't write serious applications in vanilla JavaScript without hitting a
> complexity wall.

 _closes tab_

------
gchokov
Oh.. and another one.

------
integricho
[https://xkcd.com/927/](https://xkcd.com/927/)

------
smnplk
I can not keep up with all the new X flavored js frameworks, where X is
[React, Angular, Vue, Mithril, Redux, Mobx,...]. This is exactly why I chose
Clojurescript for my pet stuff and with hopes, that I will be able to use it
for making money too. Learning curve can be steep for someone not used to
functional way and/or lisp, but at the end you get a very mature, simpler and
consistent language with great tooling. Figwheel workflow is just awesome.
Well worth the time.

~~~
grennis
I cannot keep up with random javasscript frameworks... therefore I use [random
framework in some other language]...

~~~
smnplk
It's not that I cant, I don't want to do it anymore, sorry I didn't express
myself correctly above. And there aren't that many client side framework
choices in Clojurescript, which I see as an advantage. But not everyone will
see it that way, I can understand. Whatever makes you happy.

