Svelte – The magical disappearing UI framework(svelte.technology)
svelte.technology
Svelte – The magical disappearing UI framework
https://svelte.technology/
73 comments
> 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.
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.
Oh! I think I'm fundamentally misunderstanding the pitch here. Here's my new guess: Svelte analyzes my component tree to discover the graph of data dependencies… and then throws out the component tree entirely, instead outputting code that directly implements my data flow graph.
Is that correct? If so, it's a very cool idea! (I'd been tossing this idea around for a few months last year, but had trouble designing a non-awful API xP)
I wish there were a way to make the messaging around this idea clearer. I know that audiences are different, and this wouldn't work for everyone. But if the introductory blog post had illustrated the transformation from component tree to data graph, I would've immediately understood the performance implications and how this represents a huge paradigm shift in application compilation.
Instead, though, I thought the pitch was "ew, separate runtime library? let's inline it and then it'll be smaller", which seemed misguided. I had to reverse-engineer Svelte's motivation from your comment—and even now I'm still not sure I got it right. (Maybe this entire comment is wrong? Could be wrong. No idea :/)
Are y'all planning a blog post about how Svelte works under the hood? That would go a long way toward clarifying the pitch, I think.
Is that correct? If so, it's a very cool idea! (I'd been tossing this idea around for a few months last year, but had trouble designing a non-awful API xP)
I wish there were a way to make the messaging around this idea clearer. I know that audiences are different, and this wouldn't work for everyone. But if the introductory blog post had illustrated the transformation from component tree to data graph, I would've immediately understood the performance implications and how this represents a huge paradigm shift in application compilation.
Instead, though, I thought the pitch was "ew, separate runtime library? let's inline it and then it'll be smaller", which seemed misguided. I had to reverse-engineer Svelte's motivation from your comment—and even now I'm still not sure I got it right. (Maybe this entire comment is wrong? Could be wrong. No idea :/)
Are y'all planning a blog post about how Svelte works under the hood? That would go a long way toward clarifying the pitch, I think.
Sort of, yeah. The previous wave of declarative UI libraries essentially followed one of two models — there's the 're-render the entire app then apply a diffing algorithm' approach (React and its many imitators), and there's the data-binding approach (Knockout, Rivets, Ractive and later Vue) whereby different nodes in your model/state/data graph (whatever you want to call it) are linked to the DOM, usually via various levels of indirection.
Both are solid ideas. (As the creator of Ractive I'm biased towards data-binding, but React's success speaks for itself.) But either way, the library has to do a lot of work to essentially just translate state changes into `element.setAttribute('foo', 'whatever')` and so on. Svelte was born out of a realisation that if you can understand the shape of your component graph at build time, you can eliminate those runtime abstractions — and with it, both the bytes and the computational cost associated with them.
> Are y'all planning a blog post about how Svelte works under the hood?
Yes, we have a lot of blog posts we need to write! Hopefully soon.
Both are solid ideas. (As the creator of Ractive I'm biased towards data-binding, but React's success speaks for itself.) But either way, the library has to do a lot of work to essentially just translate state changes into `element.setAttribute('foo', 'whatever')` and so on. Svelte was born out of a realisation that if you can understand the shape of your component graph at build time, you can eliminate those runtime abstractions — and with it, both the bytes and the computational cost associated with them.
> Are y'all planning a blog post about how Svelte works under the hood?
Yes, we have a lot of blog posts we need to write! Hopefully soon.
Please correct me if I'm off base here, but isn't a big part of the whole virtual-dom abstraction performance?
Direct DOM updates are slow (rerender), diffing and smart patching much faster. There must be a reason for virtual doms becoming so popular, even for frameworks that don't have a 'functional' approach like React.
Direct DOM updates are slow (rerender), diffing and smart patching much faster. There must be a reason for virtual doms becoming so popular, even for frameworks that don't have a 'functional' approach like React.
Agreed with Rich, it's a misconception that virtual-dom is faster, web browsers have made significant improvement to DOM. There must be a reason why vanilla Javascript is fastest than most virtual-dom.
Inferno-1.1.0 have an error at runtime, could not test JS Framework right now. Sveltejs works.
Inferno-1.1.0 have an error at runtime, could not test JS Framework right now. Sveltejs works.
Great question! It's a very common misconception that an app that uses virtual DOM diffing somehow manages to be faster than an app that manipulates the DOM directly.
Re-rendering your entire app (i.e. creating all the nodes from scratch with innerHTML or document.createElement) is too slow for a lot of apps, and is a bad idea for lots of other reasons (losing state in form elements, etc). Virtual DOM just gives you a way to write your app as though you were re-rendering it from scratch, while still being fast enough that you can get away with it.
Svelte is significantly faster than React according to https://github.com/krausest/js-framework-benchmark, because it's taking a more direct approach to the same goal — updating existing elements or only creating/destroying them as necessary. It's also faster than Ember, Angular, Vue, etc. It's not yet quite as fast as Inferno, but it uses less memory.
Re-rendering your entire app (i.e. creating all the nodes from scratch with innerHTML or document.createElement) is too slow for a lot of apps, and is a bad idea for lots of other reasons (losing state in form elements, etc). Virtual DOM just gives you a way to write your app as though you were re-rendering it from scratch, while still being fast enough that you can get away with it.
Svelte is significantly faster than React according to https://github.com/krausest/js-framework-benchmark, because it's taking a more direct approach to the same goal — updating existing elements or only creating/destroying them as necessary. It's also faster than Ember, Angular, Vue, etc. It's not yet quite as fast as Inferno, but it uses less memory.
Virtual DOMs are used to make the rerender-everything-all-the-time approach acceptably fast, which is desirable since that approach tends to lead to nice UI code with few state related bugs. Still, this is a pretty costly way to update the UI, as the virtual DOM causes a lot of memory churn.
Hmm, okay. I'm starting to poke at the TodoMVC's compiled code in the debugger, and it's not quite the super-duper-aggressive graph conversion that I was imagining—but it's interesting to look at :)
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.
I'd like to see some performance metrics from Svelte compared to page loads with other frameworks to see where the savings are.
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
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/
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/
> 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
> Can I use webpack?
Yep, there's a webpack 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
> 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.
If you visit the REPL you can click on the 'output' button to see some sample output code: https://svelte.technology/repl
> Can I use webpack?
Yep, there's a webpack 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
> 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.
- Yes: 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.
- 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.
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?
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?
Check the REPL and compare the input to the output: https://svelte.technology/repl
you can have a look at https://github.com/jaeh/meds to see an example, online at 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.
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.
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 then code will automatically be reused.
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-framew...
So the core idea is similar to 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...
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...
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
> 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
Ha!
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.
Interesting that Rich Harris is also behind rollup and that Svelte appears to use CommonJS instead of ES modules still.
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.
"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.
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.
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.
Also, with Svelte you can do server-side rendering, which is a bit of an oxymoron with web components.
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.
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.
> 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.
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.
I agree, hence the last line in my original reply. Web components are not yet ready for (most) production work. Too be honest I'm happy the only work I do in the Web area is an SDK. We chose to use vanilla javascript and typescript over a framework as any framework should be able to pick us up. I worked with a couple of frameworks the past 2-3 years and didn't like any of them. Of course Web is relative new and it takes time to mature. For now, I'll take a pass on this one but keep an eye. They are closest to anything I could use, but let's see what a little maturity brings it.
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.
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.
How does this compare with Marko.js, which also compiles (and renders!) JavaScript on the server before sending to the client?
I think http://aurelia.io is much cleaner.
Cleaner as in? Aurelia is on the same idea as Angular 1 by the same inventor.
How does anyone even begin to start learning how to make Web 2.0 webpages with a new JS framework every week?
It's a legit question and yet the downvotes? Odd.
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?
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.
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.
I find it kinda funny because we finally have decent cross browser consistency on the front-end, which back in the day, was the main frustration point of front-end dev. Now the problem is finding a framework that you can depend on and invest in long term. Makes me wonder if the browser wars turned front-end devs into masochists and now the only way to satisfy that urge for pain is to reinvent their frameworks on a regular basis. /s
Angular isn't going away, even 1.x will probably see updates for another 3-5 years. React also isn't going anywhere with the heavy hitters behind it... although there may be some migration to react-alikes that use jsx etc, but the techniques in the apps are largely the same.
Vue.js is probably here for a while, though a little uncertain, there's definitely some desire there. I'm not sure about Polymer and web-components, I think there will definitely be more web-component packages to work from in the future, but for now, just kind of holding off myself.
I'm pretty actively following the JS world, and tbh in 2012 I felt so in over my head as npm was growing... It's gotten easier. In general, your best bet is to stay a little behind the bleeding edge and look at what the heavy hitters are investing time/money in, and beyond that what you like.
I'm pretty heavy in the React camp (including Preact, Inferno, etc)... Most of the look-alikes are compatible enough to work, or have a similar enough workflow. I happen to like the component structure, and am a fan of Redux as well. Others have hunkered down for Angular2+.
Vue.js is probably here for a while, though a little uncertain, there's definitely some desire there. I'm not sure about Polymer and web-components, I think there will definitely be more web-component packages to work from in the future, but for now, just kind of holding off myself.
I'm pretty actively following the JS world, and tbh in 2012 I felt so in over my head as npm was growing... It's gotten easier. In general, your best bet is to stay a little behind the bleeding edge and look at what the heavy hitters are investing time/money in, and beyond that what you like.
I'm pretty heavy in the React camp (including Preact, Inferno, etc)... Most of the look-alikes are compatible enough to work, or have a similar enough workflow. I happen to like the component structure, and am a fan of Redux as well. Others have hunkered down for Angular2+.
I totally agree that those things are not going to simply disappear. It just seems that every new framework supposedly has some distinct advantage that previous frameworks lack and the urge of most front-end devs is to move on to the next shiny thing. If you don't move onto the next shiny thing you are considered to be some sort of luddite or ignorant to the amazing new thing a new framework has.
So while I can pick a framework like the ones you mentioned and stick with it convincing team mates or colleagues to do the same becomes difficult.
So while I can pick a framework like the ones you mentioned and stick with it convincing team mates or colleagues to do the same becomes difficult.
Then the problem seems to be the colleagues rather than the creation of frameworks. I'm happily following all this framework turnover while totally ignoring it for actual work.
To be fair, I have had colleagues want to switch to some new framework for $reasons, but I guess I have enough sway (and we're time-constrained enough) to not do just that.
To be fair, I have had colleagues want to switch to some new framework for $reasons, but I guess I have enough sway (and we're time-constrained enough) to not do just that.
Honestly, I've been fighting an uphill battle for a long time now... I was an early adopter with node, and pretty early on the React bandwagon... I've been pretty good at picking winners/contenders, that said it's often a matter of when it hits critical mass for adoption.
@macinjosh - That is an interesting hypothesis. I've posited that the fragmentation in the Javascript community may be related to the pace of improvements in Javascript itself. Let's face it. Javascript was quite excremental a decade ago. Now, it is becoming quite nice. So, I wonder if developers bail on old JS frameworks in order to write nifty new ones using the latest language features?
I'm trying to bring "nifty" back. What do you think? No?
@tracker1 - You're kind of speaking to my point. Most of the frameworks you mention basically do the exact same thing, or subsets thereof. Does the Javascript community really have to be this fragmented to be successful? Other communities aren't. Maybe it does. I don't know, which is why I wanted to discuss it.
I'm trying to bring "nifty" back. What do you think? No?
@tracker1 - You're kind of speaking to my point. Most of the frameworks you mention basically do the exact same thing, or subsets thereof. Does the Javascript community really have to be this fragmented to be successful? Other communities aren't. Maybe it does. I don't know, which is why I wanted to discuss it.
I think you have a great point there. Javascript and browser APIs has been changing a lot and so best practices change a lot.
I am not sure why it is taking so long for things to gel in JS/DOM land though. My best guess is that it is because JS is essentially the only programming language that can be used in the browser. Programmers coming from a myriad of different language backgrounds have to use it and they use it in ways that make the most sense to them. If you're a python dev you still have to use JS on the front-end. If you're a PHP dev still gotta use JS. etc. etc. It is all things to all people and thats not easy.
I am not sure why it is taking so long for things to gel in JS/DOM land though. My best guess is that it is because JS is essentially the only programming language that can be used in the browser. Programmers coming from a myriad of different language backgrounds have to use it and they use it in ways that make the most sense to them. If you're a python dev you still have to use JS on the front-end. If you're a PHP dev still gotta use JS. etc. etc. It is all things to all people and thats not easy.
Counterarguments:
The older libraries (that caught on) are still perfectly fine to use. There's no reason you can't still be running an Express.js app with Backbone.js + RequireJS (for modules) in the front-end.
We have a Backbone.js + RequireJS app at work and it's totally fine, well structured OOP, and arguably a great codebase in comparison to some Angular 1 architecture horror-stories I've heard about.
Of course it takes strong, level-headed devs to say "no we're not rewriting it in Angular".
In terms of jobs, being able to search for 'framework + jobs' is kind of insane anyway. 'language + jobs' makes more sense, a dev should be able to pickup any framework pretty quickly.
Not everyone in the Ruby community was that happy that Rails become so defining, you could argue that it was an anomaly to have a language so dominated by 1 framework.
That said I do prefer Rails/Django over any backend Node framework to-date, at least when it comes to the DB/ORMs/migrations story (which then lead to mature CMSs too), so I don't love that no Node backend framework grew comparable mindshare there.
The older libraries (that caught on) are still perfectly fine to use. There's no reason you can't still be running an Express.js app with Backbone.js + RequireJS (for modules) in the front-end.
We have a Backbone.js + RequireJS app at work and it's totally fine, well structured OOP, and arguably a great codebase in comparison to some Angular 1 architecture horror-stories I've heard about.
Of course it takes strong, level-headed devs to say "no we're not rewriting it in Angular".
In terms of jobs, being able to search for 'framework + jobs' is kind of insane anyway. 'language + jobs' makes more sense, a dev should be able to pickup any framework pretty quickly.
Not everyone in the Ruby community was that happy that Rails become so defining, you could argue that it was an anomaly to have a language so dominated by 1 framework.
That said I do prefer Rails/Django over any backend Node framework to-date, at least when it comes to the DB/ORMs/migrations story (which then lead to mature CMSs too), so I don't love that no Node backend framework grew comparable mindshare there.
Thank you for your commentary, allover. You do bring up a good point, I think. It does address a slightly different issue than I wanted to bring up though.
Consider this: I can still use Delphi to make Windows apps too, but where am I going to find a job? Being able to use an old tool isn't my point. My point is that while you may still be using Express.js where you work, there are many other Javascript companies who aren't using it anymore. They've moved on. Even the Express.js developers have moved on to something else (Koa), so by mastering Express.js, you sort of paint yourself into a corner in your career. You most likely won't show up on recruiting radars, since you don't have the latest JS buzzwords on your résumé, and if you try to go get another Express.js job on your own, you'll have a more difficult time of it. The high turnover rate of JS frameworks works to your detriment, I would think, because it is more difficult to keep up with all the moving targets.
If JS programmers don't see their framework-du-jour culture as a problem, then by all means, keep doing it. I just think you'd be better off, and attract more developers, if you congregated around the best framework or two out there, and worked to make them the best they can be, instead of re-inventing the wheel every other day. I'm simply bringing it up as a point to consider for making the JS community more stable and cohesive, and worthy of personal investment. I know this fly-by-night aspect of the Javascript community is one of the reasons I don't bother with server-side JS. I know a lot of other developers in my area who feel the same way.
Just something to consider...
Consider this: I can still use Delphi to make Windows apps too, but where am I going to find a job? Being able to use an old tool isn't my point. My point is that while you may still be using Express.js where you work, there are many other Javascript companies who aren't using it anymore. They've moved on. Even the Express.js developers have moved on to something else (Koa), so by mastering Express.js, you sort of paint yourself into a corner in your career. You most likely won't show up on recruiting radars, since you don't have the latest JS buzzwords on your résumé, and if you try to go get another Express.js job on your own, you'll have a more difficult time of it. The high turnover rate of JS frameworks works to your detriment, I would think, because it is more difficult to keep up with all the moving targets.
If JS programmers don't see their framework-du-jour culture as a problem, then by all means, keep doing it. I just think you'd be better off, and attract more developers, if you congregated around the best framework or two out there, and worked to make them the best they can be, instead of re-inventing the wheel every other day. I'm simply bringing it up as a point to consider for making the JS community more stable and cohesive, and worthy of personal investment. I know this fly-by-night aspect of the Javascript community is one of the reasons I don't bother with server-side JS. I know a lot of other developers in my area who feel the same way.
Just something to consider...
> JS programmers don't see their framework-du-jour culture ...
> The high turnover rate of JS frameworks ...
> this fly-by-night aspect of the Javascript community ..
All those things are your interpretation. But please hesitate when generalising like that and stating your opinions as fact, and think about what is actually going on here.
The JS community is larger than any other, and very good at promoting its stuff (great landing pages/demos/docs, lots of conferences, podcasts and bloggers).
This can give the appearance we're switching tools all the time, but actually in the few jobs I've worked, that simply wasn't the case.
And on Express.js specificially, that is not a great example of your point at all. Express is still the defacto winner by my understanding. I wouldn't pick Koa, because it's a niche thing to use a framework built around generators. The fact that original Express people went on to work on it is irrelevant (though I see it could be a confusing signal to the community).
And again I want to reiterate on the jobs thing, that (in my opinion, granted) you are not painting yourself into a corner picking any one framework because recruiters shouldn't be looking for any specific framework, and if you find in your interactions with them that they are, then it's up to you to set them straight.
> The high turnover rate of JS frameworks ...
> this fly-by-night aspect of the Javascript community ..
All those things are your interpretation. But please hesitate when generalising like that and stating your opinions as fact, and think about what is actually going on here.
The JS community is larger than any other, and very good at promoting its stuff (great landing pages/demos/docs, lots of conferences, podcasts and bloggers).
This can give the appearance we're switching tools all the time, but actually in the few jobs I've worked, that simply wasn't the case.
And on Express.js specificially, that is not a great example of your point at all. Express is still the defacto winner by my understanding. I wouldn't pick Koa, because it's a niche thing to use a framework built around generators. The fact that original Express people went on to work on it is irrelevant (though I see it could be a confusing signal to the community).
And again I want to reiterate on the jobs thing, that (in my opinion, granted) you are not painting yourself into a corner picking any one framework because recruiters shouldn't be looking for any specific framework, and if you find in your interactions with them that they are, then it's up to you to set them straight.
I'd counter your last point and ask is an ORM really necessary... especially since most DBMS with Node modules have tagged template literals to parameterized queries. In general the responses from databases are usually very easy to use without the cruft and limitations regarding ORMS.
As for migrations, I'm a little more old-school, I prefer versioned scripts/rollbacks that are hand-crafted for SQL, or for very large document/column databases on-read/save upgrades.
Backbone works... though I was in the browserify camp over requirejs/amd, mainly because I wanted the same syntax/modules without umd overhead... moving towards Webpack was a sinch.
Keeping what works is often a good idea, I wouldn't suggest even trying to rewrite everything in one pass for most things. To GP, almost everything revolves around Express server-side, there are other options, but that's still the bulk of the mindshare in my experience, even if I do like the way Koa works slightly better.
For that matter, jQuery really rules the world still, even if the mindshare has declines, and likely wouldn't reach for it for new projects.
As for migrations, I'm a little more old-school, I prefer versioned scripts/rollbacks that are hand-crafted for SQL, or for very large document/column databases on-read/save upgrades.
Backbone works... though I was in the browserify camp over requirejs/amd, mainly because I wanted the same syntax/modules without umd overhead... moving towards Webpack was a sinch.
Keeping what works is often a good idea, I wouldn't suggest even trying to rewrite everything in one pass for most things. To GP, almost everything revolves around Express server-side, there are other options, but that's still the bulk of the mindshare in my experience, even if I do like the way Koa works slightly better.
For that matter, jQuery really rules the world still, even if the mindshare has declines, and likely wouldn't reach for it for new projects.
Code generation, the frontend craze must have arrived at the Java enterprise deadends.
Time to mount the JET emitters and blast out that code.
Time to mount the JET emitters and blast out that code.
Whenever and wherever I read "rock solid" I stop reading... I hate that expression so much!
Why?
I agree. Whenever I read 'rock-solid' my distrust alarm goes off and it's almost always reading some buzzword laden marketing text.
Because it expresses the authors confidence but doesn't give anything informative. Show me metrics, features, idioms and working examples.
Meanwhile, you can download and try the sample code.
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.
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.
Something tells me, should svelt get to the number of stars that React and Angular have, you'll see a similar number of issues.
At a minimum, it's a bad comparison metric. It's like with any software rewrite: the first 80% is the easy part. It's when you get down to the fine details of handling specific edge cases that things get really complicated. (Seeing this in a rewrite I've been working on myself.)
Semi-similarly, there's three reasons why React (and other libs) have that many issues: they've been around for a while, they're very popular, and the wide variety of usages has led to a number of edge cases being found. Svelte, being new, hasn't run into any of those things yet. Things like style of development can also affect things - some communities might file more issues than others.
Semi-similarly, there's three reasons why React (and other libs) have that many issues: they've been around for a while, they're very popular, and the wide variety of usages has led to a number of edge cases being found. Svelte, being new, hasn't run into any of those things yet. Things like style of development can also affect things - some communities might file more issues than others.
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.
Should I feel happy that my js crap compiles into the other js crap?
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.
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.
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.
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.
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.
'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.
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.
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.
It doesn't seem like you care (I guess rightfully), just a note.
They should probably release an americanized version called "swell" - http://www.urbandictionary.com/define.php?term=swell
>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).
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).
Perhaps. I wonder if other people think the same way.
Coincidentally, it is also in the title here (arstechnica.com):
https://news.ycombinator.com/item?id=13349986
http://arstechnica.com/gadgets/2017/01/dells-latest-xps-13-d...
So your friend programmers may take note that it is a valid word.
https://news.ycombinator.com/item?id=13349986
http://arstechnica.com/gadgets/2017/01/dells-latest-xps-13-d...
So your friend programmers may take note that it is a valid word.
No one is saying it isn't a valid word, though.
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.