19 ms·
Svelte – A UI framework that compiles into tiny standalone JavaScript modules
- ChemicalScum 10y agoI 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.
- santialbo 10y agoAngular2 is doing a similar thing.
- toddmorey 10y agoAlways one of my favorite features of riotjs
- ergo14 10y agoWeb components and polymer solve this problem "completly" by full encapsulation. With some css preprocessing + vulcanizing you can even use separate js/css files from your component templates if that is your thing - they can get inlined in the build process.
- minxomat 10y agoA 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 10y agoCreate an issue here: https://github.com/sveltejs/svelte.technology https://github.com/sveltejs/svelte.technology or submit a pull request
- hood_syntax 10y agoNot 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 10y agoLots of elderly programmers might want to check out Svelte.
- amelius 10y ago> 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 10y agoThe 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.
- Touche 10y agoVanilla JS has long been used to refer to a lower-level JavaScript; ie not using any abstractions. Vanilla JS was often used to compare to jQuery. Of course jQuery is JavaScript.
- gchokov 10y agoOh.. and another one.
- bryanlarsen 10y agoPrecompilation 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 10y agoHandlebars 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=44e20b4e0224617d228e3c38c119ee76 https://svelte.technology/repl/?gist=44e20b4e0224617d228e3c3...
- majewsky 10y agoTried to click the link, but the REPL is apparently so advanced that it won't even display the source code in Firefox.
- rich_harris 10y agoThe Svelte compiler uses some ES2015 features (for...of, etc) that aren't currently supported in all browsers. It's designed primarily for use in Node.
- theasker 10y agoAlso doesn't work on Safari 9. Why not transpile the Svelte compiler to ES5 so it will run on all browsers? Otherwise devs may get the impression Svelte generated applications will not work on all browsers.
- skrebbel 10y agoLove 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.
- k__ 10y agoYes. I have the feeling most programmers are just lazy, that's why they use 2WB. And I can't blame them. Redux is much more boilerplate than MobX, for example.
- ryanbrunner 10y agoTrying to avoid boilerplate is in my experience not about laziness - especially when you consider the extreme lengths a lot of developers will go to to eliminate duplication and boilerplate from their codebases. Copying a Redux reducer that implements a standard set of CRUD actions is lazier in my mind than trying to abstract common patterns away. For me at least, the reason boilerplate bothers me so much is that it impacts the readability of my code. Ideally, I'd like my codebase to express the business requirements of my solution as succinctly as possible - every line of boilerplate code I need to include to express yet again how to make an AJAX call, or update a piece of state, is a distraction from what I'm actually trying to accomplish with the application.
- k__ 10y ago"the reason boilerplate bothers me so much is that it impacts the readability of my code" But if you hide boilerplate you not really improve readability. Not seeing what is really happening just creates the illusion of readability.
- throwaway13337 10y agohttps://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 10y agoIt's based heavily on Ractive (http://ractivejs.org http://ractivejs.org), which Vue is very similar to.
- spiffytech 10y agoShould users evaluate both Svelt and Ractive, or should Ractive be considered deprecated in favor of Svelte?
- BillFranklin 10y ago> # Getting started > Normally, this is the part where the instructions would tell you to add a <script> tag to your page or install something from npm. But because Svelte runs at build time, it works a little bit differently. > First, install the CLI: > npm install -g svelte-cli They might want to change their opening
- rich_harris 10y agoTo what?
- GavinMcG 10y agoSomething that doesn't say "normally, you'd be asked here to install something from npm, but" and then immediately goes on to ask that you install something from npm.
- hood_syntax 10y ago> or install something from npm > installs something from npm
- spraak 10y agoThe '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
- ricardobeat 10y agoReact also uses curly braces for interpolation, not that different.
- ryanbrunner 10y agoI would imagine that he meant the control-structure stuff like {#if}, rather than pure JS.
- ricardobeat 10y agoYeah I interpreted his comment to be about syntax. OTOH React (JSX) lacks these control structures inline in the templates, it has to be done in separate steps, not a clear win for all situations.
- hesarenu 10y agoYep. For me React JSX simplifies component building.
- boubiyeah 10y agoYeah, 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.
- jlebrech 10y agoi 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?
- pwr 10y agoIsn'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
- rich_harris 10y agoUnfortunately, UI frameworks are extremely hard to modularize in a way that makes them amenable to tree-shaking. So you're left with the alternative – cobbling together your own pseudo-framework out of 'small modules', which loses all the ergonomic advantages of a good framework. As you might imagine, I've been thinking about this problem for a long time :)
- mvindahl 10y agoAs 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.
- deleted 10y ago[deleted]
- integricho 10y agohttps://xkcd.com/927/ https://xkcd.com/927/
- dotancohen 10y agoThis 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-framework/ https://svelte.technology/blog/frameworks-without-the-framew...): > 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 10y agoI 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.
- deleted 10y ago[deleted]
- marrs 10y agoI wondered that as well at first but then I realised that it probably doesn't have much shared code as it will be using the DOM directly and that is the shared dependency
- dchest 10y agoYup. From reddit comment by lhorie: I tried peeking at the EachBlock example and it came out at 7.5kb uncompressed. Copying and pasting the loop a few times makes that grow fairly quickly. Four copies of that example code is enough to make it grow over 22kb. For comparison, the render method in Mithril.js is about 21kb uncompressed. I imagine you would only need another 20 or 30 times more code to reach the size of React (~140kb). https://www.reddit.com/r/javascript/comments/5fcwhz/svelte_the_magical_disappearing_ui_framework/dajg123/ https://www.reddit.com/r/javascript/comments/5fcwhz/svelte_t...
- Retr0spectrum 10y agoAre there any apps currently made with this?
- deleted 10y ago[deleted]
- constantlm 10y agoThis looks like a very stripped down Ember.js - it also looks pretty awesome.
- max_ 10y agoMores like Sass for JS. exactly what we need!
- catshirt 10y agoReact 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=0ed5146aa22c28410dfcff2050f3d2f8 https://svelte.technology/repl/?gist=0ed5146aa22c28410dfcff2...
- wiradikusuma 10y agoSo this is like GWT, minus Java? GWT's treeshaker removes dead code and outputs fat-free plain JS.
- boubiyeah 10y agoGWT 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.
- laurent123456 10y agoThat seems quite amazing, especially the todo example being over 10 times smaller than the React one. Are there any drawbacks to this approach?
- boubiyeah 10y agoTo 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.
- deleted 10y ago[deleted]
- nkkollaw 10y agoI 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.
- devdoomari 10y agocheckout css-modules! https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
- nkkollaw 10y agoNice. I've tried a few solutions to add styles to React components but they all had something that didn't make them see as the perfect solution. This looks very good, I've never tried it before. Thanks.
- boubiyeah 10y agoYep, happily using css modules too. The only tiny issue left with that approach is that you still can't share code (for instance, colors) between JS & CSS. but overall, I think it's the best compromise today.
- TheAceOfHearts 10y agoLook at css-module-values [0]. It's not perfect, but it lets you share values between JS and CSS. All values in the file are visible on the imported module. [0] https://github.com/css-modules/postcss-modules-values https://github.com/css-modules/postcss-modules-values
- the_duke 10y agoVue.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
- sheeshkebab 10y agothere is always room for a framework smaller than other frameworks. mature frameworks tend to get bloated overtime, become hard to reason about and learn for new developers. if it wasn't for projects like that we'd be coding in some feature rich ims/cobol framework.
- rich_harris 10y agoAs well as generating smaller apps and being quicker to load, Svelte is significantly faster than Vue. We'll be publishing benchmarks soon.
- the_duke 10y agoI'd love to see code size and performance comparison for a relatively simple but non trivial component, like a DateTime picker.
- rich_harris 10y agoYep, 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
- crudbug 10y agoLove 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 10y agoTotally agree. I just can't see myself going back to templates with special DSL. I rather just use JS :)
- netcommentator 10y agoHere's another JSX with Web Components: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder Unlike React etc this lib used W3 Components which are far superior because of Shadow DOM, which is already implemented in Chrome.
- dodyg 10y agoRich Harris created RactiveJs, which is an awesome UI framework on its own right.
- theasker 10y agoRich Harris also created rollup and buble. He's an inventing and implementing machine.
- danesparza 10y agoWhere is this being used right now in production?
- victorvation 10y agoLikely nowhere yet, seeing as Svelte is four days old (give or take a few hours).
- nilved 10y ago> You can't write serious applications in vanilla JavaScript without hitting a complexity wall. closes tab
- thomasstephn 10y agohttp://dayssincelastjavascriptframework.com/ http://dayssincelastjavascriptframework.com/
- ialex 10y agodoes it ever goes higher than 0?
- smnplk 10y agoI 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 10y agoI cannot keep up with random javasscript frameworks... therefore I use [random framework in some other language]...
- smnplk 10y agoIt'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.
- psion 10y agoWhy 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 10y ago"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 10y agoThat reasoning quickly falls apart when you throw a cache in front of your backend.
- tim333 10y agoI guess it depends on the use case. Sometimes the thing can respond quicker to user inputs if everything is in the browser.
- debaserab2 10y agoYou certainly can. Plenty of people still do. It's hard to build in an interactive user interface when you have to wait for full page loads to complete between actions. It can be done with thoughtful planning, but sooner or letter that JS you sprinkle in to do view manipulation is going to be unwieldy.
- ng12 10y agoI'm not sure what you're advocating for. Most of what you're doing in React/Angular is exactly that -- grabbing data from the backend and displaying it in some view, then handling interactions. If you're building an application and not just a website there's not really any other option.
- 10y ago
- goliatone 10y agoThis 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 10y agoI 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 10y ago> I feel its future is uncertain so it's hard to recommend others begin using it. Self-fulfilling prophecy unfortunately.
- draw_down 10y agoPerhaps, 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 10y ago>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
- blauditore 10y ago> 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 10y agoYou can if everyone in the team is at least pretty good
- bryanrasmussen 10y ago'pretty good' sounds like a doable metric for a small team.
- blauditore 10y agoYeah, and one of the trade-offs is that you need to stick to certain conventions that are somewhat enforced by frameworks.
- gildas 10y agoI agree. Ten years ago, writing application in vanilla JS was hard because of the browser incompatibilities. Today, browser vendors really do an effort to avoid such issues. Furthermore, today the DOM API is very well documented and, over time, I find it getting easier to learn and use.
- mercer 10y agoI agree that it's become feasible, but even for relatively 'light' scripting my experience is that already very soon something like jQuery becomes worth using despite the increase in payload size. For example, I'm currently working on a project with mostly plain js, and I've already had to spend quite a bit of time adding code to make relatively basic things work across browsers (including mobile). Even though it's much less work than it used to be, it's still extra time and code that others will now also have to understand. And who knows what other browser issues linger or will pop up as more features are added! The worst part is that if I'd be allowed to lazy load some of the images and make a few small other optimizations, I would've shaved off enough Kb's to load multiple version of jQuery...
- ng12 10y agoHow is this substantially different from Backbone/Marionette? I feel like we're regressing.
- boubiyeah 10y agoBecause 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.
- ernsheong 10y agoyou still have to download the backbone.min.js file
- fzaninotto 10y agoThe 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 10y agoHaven'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.
- boubiyeah 10y agoCheck the generated code in the REPL, it's straight DOM manipulations.
- mvindahl 10y agoHope they have good reasons, then..
- JDDunn9 10y agoThe 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 10y agoI'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.
- devdoomari 10y agohow about porting this to scalaJS? would be awesome to use scala's typechecking on this (especially on template strings)
- brilliantcode 10y agoSo 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 10y agoI 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-Registration https://vuejs.org/v2/guide/components.html#Local-Registratio...). 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-expression-sandbox-removal.html https://angularjs.blogspot.co.uk/2016/09/angular-16-expressi... 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.
- eob 10y agoLooks 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 10y agoPolymer is an enormous library.
- eob 10y agoPolymer 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.
- ergo14 10y agoThats completly untrue - polymer is close in size to jquery and a lot smaller than react core for example.
- abdonrd 10y agoNo, it's a little library. And smaller in Polymer 2.0. :)
- mwcampbell 10y agoI 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 10y agoBut 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
- grzm 10y agoIt's a key component of the ClojureScript tool chain.
- camwest 10y agoDon't quote me on this but I'm pretty sure gmail uses it. I'd say that's a pretty big endorsement.
- fnordsensei 10y agoFrom 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 10y agoYeah I think I read it here: http://shop.oreilly.com/product/0636920001416.do http://shop.oreilly.com/product/0636920001416.do
- 10y ago
- hbbio 10y agoWhy 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 10y agois 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 10y agoThanks zem! Yes, Opa is still used in several projects and pretty stable. But the project is asleep and not very active as of now.
- mambodog 10y agoTodoMVC 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.
- shams93 10y agoYeah the lack if a realistic benchmarking tool is a major part of this whole front end fatigue, is it just another project or can it realistically prove itself to be a real benefit for performance.
- mercer 10y agoFWIW Rich Harris' other stuff is pretty solid: Ractive, Rollup, Bublé.
- scotttrinh 10y agoI was very shrug-y about this new non-framework until you pointed out it was a Rich Harris project. Definitely interested now...
- progx 10y agoInteressting, it all depends on who create a project, not what the project does.
- jgalt212 10y agoI agree. Ractive is very cool, and with a little luck could have been the hotness that vue.js has developed into.
- the_jp 10y agoSo 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
- adakbar 10y agoOut 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.
- kimshibal 10y agoWe move React to Svelte at work. We saw a huge file size decrease. almost 50%.
- canyonero 10y agoWhy 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?
- SamBam 10y agoHow big was your project? How long did it take?
- fnordsensei 10y agoApparently no larger than 15 days worth of work.
- ergo14 10y agoWhy would I use this vs established and polished project like Polymer that already has a big ecosystem of components for reuse?
- untog 10y agoIf that's your requirement, you wouldn't. But every project has to start somewhere.
- SEJeff 10y agoPretty 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
- deleted 10y ago[deleted]
- uvesten 10y agoIs it possible to filter out all JS/Framework stuff from the hn feed? Asking for a friend.
- crazysim 10y agoWrite a some JS for a userscript?
- jbeja 10y agoI was thinking in this very same idea. Awesome, can wait to give it a try.
- jbeja 10y agoI was thinking in a very similar idea. Awesome, can wait to give a try.
- tycho01 10y agoThis compiler sounds similar to me as the Ahead-of-Time (AoT) compiler currently shipped in Angular 2.
- sapeien 10y agoThis 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.