Web Development Simplified with Svelte

https://objectcomputing.com/resources/publications/sett/july-2019-web-dev-simplified-with-svelte

by gavreh • 7 years ago

254 159 7 years ago

urthen• 7 years ago

I'm a primarily React-based developer, but have taken to using Svelte on side projects. Don't get me wrong, I still like React, but Svelte is phenomenally easy to get started and wrap your head around. I've started suggesting it instead of React to people looking to learn front-end JS.

skinnymuch• 7 years ago

How long did it take to get semi comfy with Svelte (from recent React background)?

spoiler4• 7 years ago

For me, it didn't take long. I was initially confused by some "repurposed" syntax in svelte, and kinda felt negatively about it, but I grew to accept it, and even appreciate it (it's a hack, but on the elegant side). There's quite a bit of "repurposing" going on (probably so svelte can work with existing linters and other tooling), but you get used to it.

Svelte has more often "magic" stuff, but the good thing is the magic is simple, and it easy to understand (especially since you can easily look at the compiled output, if you want to double check)

treggle4• 7 years ago

How is it different and what’s so good about it?

GoToRO• 7 years ago

From what I know it's a compiler, so it check all the things at compile time and not waste time at run time.

rmilejczz• 7 years ago

The main draw is that Svelte apps have no dependencies at runtime, instead it compiles a pure vanilla js bundle that relies on existing web APIs to do updates. This is attractive to a lot of people, me included, but imo Svelte isn’t quite production ready yet (at least for complex apps). It’s great for small projects though and I highly recommend checking it out

mellosouls4• 7 years ago

I read the main article which took some time to reach the conclusion a small footprint was the main point.

So I googled, found the Svelte homepage, and I'm still none the wiser as to why it might be an easy intro to web development.

Honestly, if Svelte is as easy as you suggest to get your head around, somebody needs to work on the presentation of that.

treggle4• 7 years ago

Agreed. Lots of praise, no explanation.

spoiler4• 7 years ago

I feel like like saying svelte is an "easy intro to web development" is misleading. The svelte compiler "abuses" (I don't mean it in a bad way) existing technology so it doesn't have to create special tooling and works with existing tools. I think that's okay _only if_ you're aware of this as a developer.

If I was hiring a JS dev, and someone _only_ had svelte on their CV, I'd be a bit reluctant to hire them, only because the svelte compiler hides a lot of JS warts (which I think people should be aware of).

cpfohl4• 7 years ago

Did you walk through the tutorial? It's _easy_. And the tutorial is kept almost 100% up to date with svelte version changes.

mvolkmann6• 7 years ago

If you are referring to my article, "small footprint" is not the main point for me. The main point is ease development due to features like easier component state management, app state management with stores and sharing data between components with context.

_eric• 7 years ago

Are you using Svelte for SPAs? If so, what are you using for routing?

felideon4• 7 years ago

I use Svelte with Sapper, which takes care of routing for me. From the FAQ:

Is there a router?
You can use any router lib you want. A lot of people use page.js. There's also navaid, which is very similar. If you prefer a declarative HTML approach, there's svero and svelte-routing.
If you need hash-based routing on the client side, check out svelte-spa-router, or abstract-state-router, a mature router for business software.
For an official solution, there's nothing that's simply a routing library. There is, however, the official Sapper framework, a Next.js-style application framework built on Svelte, which includes its own filesystem-based routing.

nailer4• 7 years ago

I use Svero. Sapper is alpha and still in flux - I'll check out Sapper again once it's stable though.

vcoelho• 7 years ago

I felt the same way when I discovered Vue after a long time using React.

Bantros• 7 years ago

This is a framework I've been interested in for while. Need to find an excuse to use it

onion2k3• 7 years ago

The fact you can easily make yet another To Do list app isn't very useful. If you can't easily make a very simple app then something is seriously wrong with the framework.

A much more useful question is whether or not a framework makes it easier (or faster, or better, or something) to write a complex app. In the case of Svelte, all the hard stuff (eg state management, sync'ing data from APIs, etc) is outside of the scope framework. That make Svelte much smaller and simpler, but it makes writing a complex app harder (because you need to glue some other libraries together yourself; the framework isn't doing it for you).

rimliu2• 7 years ago

This is not different from React, which is just a view library.

myrryr• 7 years ago

Except it isn't, it's a compiler rather than just a view library.

The point is it ain't just a view library, and once you have your own compiler you can get more done.

cpfohl4• 7 years ago

State Management is a first-class part of svelte, check out their `Store` implementation.

https://svelte.dev/tutorial/writable-stores

It only took me a few hours to fully appreciate what a tidy solution Svelte's store implementation was.

As far as syncing data from APIs: I am pretty sure that it should be out of scope for _any_ view layer. APIs vary widely, and it wouldn't be appropriate for a view tool (Svelte, React, Vue, etc) to have an opinion. It's really up to the developer, and for the most part (and I may have a controversial opinion here?) should be a pretty simple set of wrappers around `fetch`). Where's Vue or React's API consumption tooling?

hamilton• 7 years ago

From experience building more complex apps in Svelte, I can say that this has not been my experience, & doesn't accurately depict React in practice. Three aspects that make it really killer – a really great story for handling app & component state cleanly regardless of complexity, a great style scoping story, and powerful transition / animation primitives that fit neatly into the idiom – has made it easier to build large data apps than I've found with React (which I also use).

Another aspect I have really appreciated is that I have substantially fewer dependencies, since there is more included in Svelte than in React. I tend to only use d3 utility functions (format, scales, etc.) & immer (which I pair with svelte stores to get something kind of Redux-y, which is great for other devs jumping into Svelte from React-land). Fewer dependencies means I'm less likely to encounter awful dependency hell.

Generally, I feel like every time I see a Svelte thread here, there's a lot of random noise, but it's good to listen to the folks who actually use it. There are situations where it makes sense, and situations where it probably doesn't. The main reason why I might not use it is ecosystem friction – a lot of devs I know would prefer to just use what they know, even if it is painful relative to Svelte & friends.

mokanfar• 7 years ago

There are situations where it makes sense, and situations where it probably doesn't.

I have been working with svelte for quite some time now, and honestly I can not think of a time where it did not make sense to use it. At its most basic form, its compiles down to vanilla javascript with a small footprint and offers a tidy workspace when working with html/css/es6.

mrtksn2• 7 years ago

I've been distanced from web development for a year and you now have a cool new framework, ReactJS is surpassed by VueJS and probably some other packaging tools did something interesting and new opinions about how the same old things should be built are on the rise.

But I have a serious question: Why the web dev is still a relevant thing? Don't get me wrong, I won't argue that the web is dead and all should move into AI or VR or something but I am under the impression that most of the problems that can be solved through a Web UI are mostly solved. Sure people come up with interesting business ideas all the time but they usually don't require innovative Web UI tech and can be built just fine with 10-year-old frameworks.

How is the web world doing? Why would anyone keep creating cool new frameworks?

treggle4• 7 years ago

No vuejs did not surpass reactjs.

In fact reactjs found an even simpler programming model and is leading with this new approach ... it is called hooks.

Vuejs is copying the same concept and in fact wanted to dump it’s old way to fully embrace react hooks style programming but that angered the vuejs community.

nailer4• 7 years ago

I don't think React is really competing with Vue as much anymore. Solving the problems of a virtual DOM in a better way is a minor improvement compared to not having a virtual DOM at all. The older virtual DOM frameworks are competing with Svelte.

spoiler4• 7 years ago

Don't get me wrong, I love hooks because I know how to use them, but there's so many easy pitfalls with them, and I constantly have to pester people about them in code reviews, if so many people in my company (and wider) misuse them by accident, it makes me me doubt how well thought out they are.

I know some people have a thing for arcane programming (for a lack of better word), but in my opinion it just makes code harder to write, understand, and even statically analyse.

Not to mention, the official lining for hooks leaves a lot to be desired for, especially because some internal React return values are treated magically by the linter (useState, useReducer to name a few) when it comes to hook dependency management.

dabernathy892• 7 years ago

I wouldn't argue that hooks is a simpler programming model, except perhaps under the hood. The Hooks API is not intuitive. I'm sure once you get a hang of it it's not hard, but as a Vue developer reading Hooks code it's not very clear.

While there was some backlash to the initial Hooks-inspired style in Vue, they went back to the drawing board and came up with a better way to explain it to the community that has gotten a much better response. I also find Vue's API for "hooks" much more intuitive/readable than React hooks, because it maps pretty well to the old style of writing code.

treggle4• 7 years ago

> Why would anyone keep creating cool new frameworks?

That’s a weird question because the answer is so obvious. There’s massive innovation in front end development because billlions of users are using ever more sophisticated applications created by millions of programmers backed by virtually infinite money. Of course people keep looking for and finding better ways to do things. Do you think that process has come to an end?

You must be trolling.

mellosouls4• 7 years ago

I thought it was a fair question.

For people not expert or completely current in web development - especially in the context of a field not unknown for jumping on every shiny new magic bullet - it's quite reasonable to ask what major problems are arising that need a new framework learning every week.

mrtksn2• 7 years ago

See, all the innovations are about code management and tracking. There has been nothing new for users for many years. In 2004 Gmail made AJAX popular and updating pages without reloading was a big deal. Later we had rounded corners, video without the Adobe Flash player, then came the websites that fit the screen size(the responsive web stuff) and later, we got some WebSocket stuff making possible real-time communications even snappier than AJAX.

That said, this is 15 years of time and the innovations came as browsers got better, IE died off but all these JS frameworks were always about making the codebase nicer.

Is there anything new for the users here? If not, why keep spawning new frameworks? Do these frameworks make anything better for the developers? In my experience, the JS world is a giant mess mostly because of the excess of frameworks that do the same things essentially.

That's why I felt burned out of web dev. I found out that all these frameworks that are supposed to make something easier to do are only making problems infinitely complex.

There's nothing new that you couldn't have done with 10 years old frameworks but now you need specialized knowledge on tons of tools.

dmitriid• 7 years ago

There’s massive innovation in front end development because billions of users are using ever more sophisticated applications created by millions of programmers backed by virtually infinite money.

There's no real innovation on the web. As another commenter pointed out, all the "innovation" is around tools. And even those innovations are meh at best.

Web has been busy reinventing things that desktop programming has had probably for decades, and what mobile development has had for years. And that's when we consider tools only.

On the app/client side the situation is even more bleak and dire. We get a 100th store implementation. A 1000th drag and drop implementation. A 10000th file upload manager. A 100000th state manager. A...

The "ever more sophisticated" applications can barely scratch the surface of native apps. And the actual more sophisticated apps like Figma are busy re-inventing and re-building the past 20 years of desktop UIs from scratch [1].

It's not innovation. It's a hamster wheel race.

[1] https://www.figma.com/blog/building-a-professional-design-to...

--- quote ---

Pulling this off was really hard; we’ve basically ended up building a browser inside a browser.

The reason this is hard is because the web wasn’t designed as a general-purpose computing platform.

--- end quote ---

onion2k3• 7 years ago

Sure people come up with interesting business ideas all the time but they usually don't require innovative Web UI tech and can be built just fine with 10-year-old frameworks.

That depends on your definition of 'just fine'. I can develop a lot faster with fewer bugs today using React than I did using jQuery a decade ago. That means the apps I build cost less (or more commonly my clients get more functionality for their money). They seem think that's a really big improvement.

wolco• 7 years ago

Of all the things I've heard over the years no one has ever said jquery created more bugs than react that's why I switched. Or that it was faster to develop.

Slower, bundling sizes, hard to maintain, doesn't manage state, complexity is messy but never few bugs or slower to work with or different to understand.

rahilb• 7 years ago

My personal view is that the 'what' in frontend development generally isn't super interesting and most web frontends are very similar; if you do not focus on new tooling, you will just do the same thing over and over which is unsatisfying.

If you're a very smart dev at one of the biggest tech companies in the world, getting paid a quarter of a million dollars per year working on a niche team that handles a small section of a single product, you will probably get bored pretty quickly and start focusing on the how. It's a shame really; some of the greatest minds of our generation are being put into rooms to work on animations for buttons on virtual DVD cases and Photo Books.

The silver lining is all these tools are given away for free. The tools so great and their corporate creators so cool that you can just have them! A cynical reading is that they are only given away because the competition can derive no value from them... In fact, forcing your competitors to retrain every 6 months when you release another major version that breaks all existing projects will only slow them down and fill your coffers! The new whatsapp will never get off the ground, because the devs were too busy rewriting babel files and the money ran out... you just saved a cool $18bn.

If these frameworks were really the key to anyone's successful business you would not know that they exist.

airstrike• 7 years ago

if you do not focus on new tooling, you will just do the same thing over and over which is unsatisfying.

I have no idea how you go from "knowing what you're doing" to "unsatisfying"

oblio• 7 years ago

A cynical reading is that they are only given away because the competition can derive no value from them... In fact, forcing your competitors to retrain every 6 months when you release another major version that breaks all existing projects will only slow them down and fill your coffers!

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

As a sort of side note, amusingly, Microsoft is rarely included in the FANG-style acronyms. There's a reason for that, Microsoft is the granddaddy of FANGs, from a strategy perspective :-)

mvolkmann6• 7 years ago

You said "My personal view is that the 'what' in frontend development generally isn't super interesting and most web frontends are very similar." I think if you take a serious look at Svelte you will see that it is much simpler than the current popular web frameworks.

kenny87• 7 years ago

some of the greatest minds of our generation are being put into rooms to work on animations for buttons on virtual DVD cases and Photo Books.

why thank you sir!

giancarlostoro• 7 years ago

For performance and to improve the development workflow.

WebAssembly looks amazing. Much faster web applications. Then you have stuff like Hudini which will let you create custom DOM elements and allow open source web frameworks to provide really sane DOM element offerings.

WebAssembly has the largest potential. Just look at Microsofts Blazor project. If you do any .NET Blazor looks even more amazing! Then Microsoft also has React Native for Windows.

boomlinde2• 7 years ago

For performance and to improve the development workflow.

If it's for performance, the community as a whole seems to have failed entirely. Svelte looks like an exception, sure, but websites generally use more CPU time, more RAM, more bandwidth than they did 10 years ago even when they don't do anything significantly different, functionally.

heydenberk• 7 years ago

I encounter this impression a lot and find it a bit confusing. I suppose this is what it looks like at a distance, because at a distance you see news and headlines, not practical realities. In point of fact, I think the VueJS boomlet is over, and I doubt its uptake got anywhere near ReactJS. The community has by and large settled on Webpack for building and bundling, and Webpack itself is quite stable after a few years of finding the right API and its proper place in the stack. Finally, the community seems to be converging on TypeScript, an eminently sane compile-to-JS language, and an increasing share of the ecosystem has increasingly robust TypeScript support

julienreszka• 7 years ago

Your vision isn't based in reality. Have you seen the growth of vetur and vue browser extension weekly active users?

https://youtu.be/zB3HOejXqwk?t=302

chrshawkes2• 7 years ago

Real stable right? Like MJS files for module loading? Real stability there. It's the inmates running the asylum. We use to have to deal with IE holding things back, now it's the JS/Node community.

pixelrevision• 7 years ago

A lot of devs tend to feel that UI is something trivial and “solved”. The unfortunate reality is that UI related code gravitates towards being extremely messy, convoluted and harder to change over time. It changes more than other types of code, is really hard to test properly and has to handle coordinating events firing from all over the place. Add to this JavaScript’s lack of types and past testing culture and you can see how creating a framework that fits your needs can become an appealing option.

JMTQp8lwXL3• 7 years ago

Writing accessible web interfaces have visually parity across a handful of browsers over a matrix of many devices, is so much more challenging than writing a scalable REST backend service.

duxup• 7 years ago

is surpassed by VueJS

The web world is the wild west (and I kinda like it) but I don't think we're even close to React being surpassed by Vue.

There was a lot of talk about stars on github for Vue but I'm not sure people star what they work with every day, or at least that it means much relative to other projects.

tomp• 7 years ago

I was looking for a multiselect autocomplete component the other day. The only useful I found was from SemanticUI, and it's not quite configurable enough. I'll have to roll out my own...

wintorez2• 7 years ago

Because we want to achieve the same thing while writing less code. Because browsers advance and new APIs become available everyday. Because we now write web apps in places where there were no browsers before, like smart TVs, smart watches, etc.

ggregoire2• 7 years ago

ReactJS is surpassed by VueJS

Is it though?

- react weekly downloads 5,672,972

- vue weekly downloads 1,090,292

pzmarzly3• 7 years ago

I'm migrating one of my sites from jQuery (+ server-generated HTML) to Svelte. I like how Svelte+rollup make it easy to replace just a part of a website (take HTML from a file, put it into Foo.svelte, back in the original file insert <script>new App.Foo({target: document.body, props: { /* data */ }})</script> [0]). Instead of generating HTML, server-side scripts now generate JSON, which could be used later to make a proper API.

I don't like handling of "undefined" and "null" values in properties[1]. It would also be nice to have optional properties so that warnings wouldn't get emitted to JS console. Also, someone should investigate iOS bugs[2]. It would be bad if someone made complex site in Svelte+Sapper and only later discovered it lags on iOS.

Overall performance is okay, but it's visible to a naked eye that Svelte parts render later than the rest of the website.

All in all, I would recommend giving Svelte devs few more months before moving to it. But definitely keep an eye on it, it has great ergonomics (maybe except for styling subcomponents, but some say it's a code smell anyway).

[0] assuming you set output { format: "iife", name: "App" } in rollup.config.js, imported bundle.js in the original file, and put export { Foo } in main.js

[1] https://svelte.dev/repl/f1f2bf4c50cf4a75ba6ea38c3390af5b?ver...

[2] https://github.com/sveltejs/svelte/issues/3581

pzmarzly3• 7 years ago

Update: I take back my words about optional parameters - I didn't notice docs saying "To squelch this warning, ensure that a default is specified, even if it is undefined"[0]

[0] https://svelte.dev/docs#1_export_creates_a_component_prop

wirahx• 7 years ago

I couldn't actually figure out what you were trying to do here, but there are a few points I do understand, and can answer:

1. If you want to bind a property it needs to be declared. This is the method of least surprise.

2. I've been running three Svelte sites in production for more than a year now, and 80% of our traffic is iOS. The sites work fine, it's the tutorials specifically, probably because of the embedded REPLs which have an iOS issue.

3. You claim that the Svelte code runs later than the server-generated HTML. This makes sense, since the DOM from Svelte components is built using Javascript. If you wanted to generate Svelte code on the server-side so that it renders at the same time, you would use { ssr: true } in your rollup config and generate code for both server and client side.

4. Not sure what the notion of lag is or where it comes from, Svelte outperforms everything else (when I last checked benchmarks), and is likely to, since it has the immediate advantage of not requiring a client-side runtime to download before it starts execution.

pzmarzly3• 7 years ago

Thanks for replying. In my previous post, I just wanted to share my experience as someone who has used Svelte (for few days, though, nowhere close to how much you have).

1. I just missed the part of documentation that talks about optional properties. And with undefined and null issue, it's a bit surprising that two-way bindings behave differently that 1-way. Passing null or undefined is convenient when an API gives you such values and they represent empty there.

2. Ok. What I feared is that the tutorial would turn out not to be bugged, and Svelte would be a bad choice for CPU-intensive SPAs. Thanks for reassuring me that's not the case. I'd still love to see the fix for the tutorial bug (because at the first glance, there isn't anything that screams "wrong!" in its code).

3. Yup. I just wanted to point out it's noticeable if you look for it. I will look into SSR later.

4. Same as in point 2.

BTW I just wasted 2 hours fighting with bind:group[0][1]. This issue is an example of what I meant by saying that people may want to wait before jumping on Svelte.

[0] https://github.com/sveltejs/svelte/issues/2308

[1] https://svelte.dev/repl/efbe52272558468397b66e46fa906561?ver...

chrshawkes2• 7 years ago

I've been writing React professionally for 5 years straight and I'm absolutely sick of it. I haven't spent enough time with Svelte but I'm sick of React and all the noobs who swear by it. I'm sick of it spinning around in circles and nobody getting anywhere. I'm sick of terrible SPA's consisting of a pile of bandaids stacked on top of one another. I'm sick of testing it with tools like Enzyme. If React were so great, I'd expect to see better things coming out of Facebook. They do one thing well, steal and sell users data. Everything else was bought. Honestly, just sick of Facebook. I was more productive writing stateful apps using C# and ASP.NET with jQuery. In fact, 9/10 we don't need stateful UI's nor React.

GraphQL sucks too. Good luck setting up caching. For instance, hey we forgot caching is important, now that the architecture doesn't allow for it since it uses a single api endpoint... the talked about solution is to use localStorage or sessionStorage. JS is a huge noobfest and those that think React is the answer to everything, probably haven't been in this game long enough.

bavell2• 7 years ago

I too have been using react professionally for the last 5 years and I have the opposite take on it - I still love it as much as when I started using it. I'm a solo dev so I get to control quality end-to-end, perhaps this is where our difference in opinion stems from.

I have no doubt there is tons of awful react code out there written by noobs but the same can be said for practically any software engineering endeavor.

I'll concede that it takes time + effort to understand how to best use react but it's merely a tool and you need experience and insight to understand how best to use your tools. I try to use as little state as possible and use functional components everywhere I can. Hooks have been a big help.

I agree about having reservations with GraphQL, it doesn't seem ready for primetime to me although I'm keeping a close eye on it because I like the underlying concept.

JS is a "huge noobfest" imo because webdev is so accessible and prevalent. But today's noobs are tomorrow's professionals ;) Typescript has been a very welcome development to encourage better dev practices.

Phillips126• 7 years ago

I too have been using react professionally for the last 5 years and I have the opposite take on it...

I'm with you mostly. When I started React close to 5 years ago it was PAINFUL. Coming from mostly jQuery (single library and I'm on my way) to trying to figure out gulp, bower, webpack, babel, etc. The tooling has much improved with the release of `create-react-app`. I can't exactly say the tooling has become better as much as it has been hidden away and the defaults are mostly ideal. Yesterday I had a huge headache trying to figure out why my treeshaking wasn't working (it was bundling 1.5mb of icons into my app). Turns out I was using an old version of `react-scripts` and with it an older webpack which I may have noticed sooner had I hand-built the tooling like the old days of React.

It has become impressively complex with all of the moving parts that are required for a React app these days. Webpack alone is not for the faint of heart with all of the configuration and babel-hell that code (and other files) has to flow through. Without `create-react-app`, I would probably have left React long ago, which would be disappointing because I enjoy the syntax, hooks, readability. I've tried Angular and absolutely hated it, perhaps Svelte would be interesting to me.

sadlion• 7 years ago

Looks interesting. Is there a list of libraries that are productions ready that can be used with it? I'm looking for Formik and ReactRouter equivalents at least.

chiefalchemist3• 7 years ago

Whoa. Sounds interesting and promising. If anyone from Svelte is here listening I'd like to point out that this isn't quite correct. WCAG actually specifies that __decorative__ images have no alt= or use alt=''. But yeah, a warning can't hurt. Kudos!

Svelte provides runtime warnings for accessibility issues. For example, <img> elements that have no alt attribute are flagged.

fredleblanc3• 7 years ago

Having no alt and having alt="" do not produce the same results to the audiences relying on those attributes to perceive images. The W3C's tutorial on decorative images (found at https://www.w3.org/WAI/tutorials/images/decorative/) says to use alt="" to mark an image decorative, as some (prominent) screen readers will read the image's file name when no alt attribute is set.

But hey, that Svelte is providing these warning is great for accessibility!

chiefalchemist3• 7 years ago

Yeah. Thanks. Maybe you'll know this? Is it kosher to user aria-hidden=true for decorative images?

I'm asking because it's not easy convincing a client that alt="" is ok. They've read so many times "also have a value for alt-=. This is especially true of clients who are SEO-centric. It seems to me there should be an easy and obvious way have a decorative image with a non-blank alt=.

JTenerife• 7 years ago

Does anyone know what's the status of Typescript support in Svelte is? This thread is understandably locked:

https://github.com/sveltejs/svelte/issues/1639

Still I'm curious.

Typescript and RxJS (or MobX) with Svelte as the afterthought (https://michel.codes/blogs/ui-as-an-afterthought) would be a nice combo.

nailer4• 7 years ago

Pretty much as you can see. A lot of people want it. It's not done yet.

Obviously Svelte is a JS to JS transformative compiler - you need to make a TS to JS transformative compiler.

I'm hacking on my next app using TypeScript on the backend (particularly around the data layer) and JS/Svelte on the frontend. I would like TS on Svelte, but the rest of Svelte is compelling enough I'd still use it over older tech like React.

moogly• 7 years ago

Yeah, I love the concepts, philosophy and the simplicity of Svelte, but sadly I can't consider using it until it has proper TS support.

cies3• 7 years ago

I'm afraid Svelte with typescript will loose some of its charm. Typescript is a little more verbose and explicit, also it cannot be directly executed by the browser (so you need to compile it, yet it is intermingled with HTML at times — there's JSX for that but Svelte kinda wants to NOT go the JSX/ShadowDOM route)

Internally Svelte uses TS though, the author claims to love TS also! It just does not mix very well with Svelte.

Stencil.js and lit-element are better picks in this regard IIRC.

maitredusoi• 7 years ago

Svelte is a real good shot vs the angularjs (v1) I used in 2015, but still, I will stick to imba ;)

choward2• 7 years ago

Svelte has not yet received the attention it deserves. When it is mentioned, the focus is typically on its ability to produce bundled code that is significantly smaller than the alternatives. However, Svelte makes many tasks easier, including defining components, managing component state, managing application state, and adding animation.

Under the "Why Consider Svelte?" it only mentions bundle size and performance.

mister_hn• 7 years ago

Which is perfectly fine

rat9988• 7 years ago

It is not, I can already do that directly with the DOM. It's a huge asset, but not enough. Ease of use, development velocity or something along these lines should be mentioned.

felideon4• 7 years ago

For me, that's icing on the cake. Why I truly like and recommend Svelte is its ergonomics. Paired with Sapper, building a fast website is a breeze and feels like you're just writing plain HTML and (supercharged) JS.

paulddraper2• 7 years ago

It's perfectly fine if your most pressing issue with large bundle sizes/slow performance.

If your most pressing issue is removing bugs from managing state, you will pass it by.

mvolkmann6• 7 years ago

Not true. That section mentions several other "Whys" including this: "Svelte dramatically simplifies component and application state management. Contributing features include context, stores, and module context, each of which is covered in detail later."

lhorie5• 7 years ago

The way I see Svelte is as a one-stop-shop type of framework (similar to Angular and Ember in philosophy), but exclusively for client-side concerns, and aggressively geared towards leveraging standard web idioms (HTML that looks like HTML, CSS that looks like CSS, JS that looks like JS), whereas most competing frameworks extend grammars in various non-standard ways (Angular's "HTML" isn't parseable via a standard HTML parser, and React's "JS" requires a parser that supports JSX - and then there's the whole CSS-in-JS thing where people get tripped up by double quoting and camel casing rules). Said frameworks typically also have steeper learning curves due to framework-specific APIs.

Where I think Svelte falls a bit short (given its flavor of comprehensiveness) is that while it concerns itself with strictly client-side things like in-memory state and animations, it offers nothing for sorta-server-related things like data fetching or routing, and you're left to find libraries to fill the gaps (similar to how you would in React). I feel like the bigger frameworks are up to something DX-wise, with providing more integrated/idiomatic ways of interfacing between subsystems (e.g. getting a data fetching API to talk to a state store, or making routing aware of them). Gluing subsystems from different libraries adds weight to application space code (see e.g. react-redux vs Vue) and at some point this starts mattering (usually during maintenance phase). Maybe Svelte's middle ground is your cup of tea, but obviously YMMV a lot.

jeremyjh• 7 years ago

Have you looked at the Sapper project? I think it adds a lot of what you are looking for. It’s basically a next.js equivalent.

no_wizard• 7 years ago

You’re the guy who came up with mithril.js? If I recognize the username anyway.

Do you think mithril will solve these issues or is a good alternative?

boomlinde2• 7 years ago

it offers nothing for sorta-server-related things like data fetching

The obvious advantage of not including these kinds of things in the library is that it makes less assumptions about the data and communication model. Maybe my data source is a Websocket, a REST API, a GraphQL API, or some Electron IPC messages. Ideally, in my view, the rendering library doesn't care. It shouldn't have to understand all these things to render my view, and it definitely shouldn't assume any single one or two of them.

ConcernedCoder• 7 years ago

You want simple? Try HTML, CSS, and JavaScript.

felideon4• 7 years ago

Ergonomically, that is exactly what Svelte feels like.

NotATroll• 7 years ago

You, I like you.

mvolkmann6• 7 years ago

HTML/CSS/JavaScript has no builtin state management and no two-way binding between state and form controls. Svelte makes those things very easy.

Kye• 7 years ago

One of the more popular Mastodon frontends uses Svelte.

https://pinafore.social/

sharmi• 7 years ago

Does Svelte have a prebuilt set of components like ant.design?

turtlebits• 7 years ago

Svelte really resonates with me - as a previous AngularJS dev, tried to get into React and VueJS several times, but I did not want to learn a build system (grunt, gulp, webpack) and always have to stay up the date with the "best" ways to build. And I don't have the time to invest in learning another tool.

The nice thing about Svelte isn't necessarily the syntax. It's the fact that out of the box it builds without me having to learn how to build it. That and the small bundle sizes and single file components sealed the deal for me.

jcmontx• 7 years ago

Looks like early Vue to me

ifthenelseend• 7 years ago

Svelte is great, but I will probably use the new Blazor framework from Microsoft that compiles to WebAssembly. The benefit is that I can use C# instead of JavaScript.

cjblomqvist• 7 years ago

Unfortunately with the downside that your bundle will be quite large. Hopefully that'll get better, but most likely, due to fundamental reasons (you need to pass along a C# runtime), I doubt it'll be even remotely close to something like Svelte.

_benj3• 7 years ago

I recently started a project using svelte and the difference from React and Vue is so drastic for me that it isn't even funny!

Now, I know how opinionated we all are and how the best thing is what we already know, but after working with Vue and React extensively (the company I currently work for uses Vue/TS for a huge app, think over 1000+ .vue files) the particularity about svelte is that you hardly notice that you are using it!

Vue has the Vue way and React has prophet Abramov to light the way, but svelte is completely out of your way. You wanna follow MVC? go ahead, DDD? why not?

I have learned more HTML5 and CSS3 using svelte than any of the other frameworks because it encourages you to use it, because the wheel has been invented already.

Again, everybody has their opinion but for me svelte is the framework that has the least magic of all, the you can set it up without a incredibly complicated webpack config or obscure 'create-react-app' that makes it very easy to start a project but you don't really know what's happening underneath.

And it just HTML and probably 5 or 6 extra JS things like $: and a different use for export in a component.

If you are already religious about your framework, good for you, but if you are open to ideas, take a look a svelte!

JMTQp8lwXL3• 7 years ago

If you really want something that will get of your way, use Web Components. They're a web standard, after all.

_benj3• 7 years ago

I read an article about them recently. I love the idea of an standard but it feels so "committee design" with a lot of good ideas but completely throwing out the window simplicity.

The older I get as a developer the more I realize that simple is not easy to accomplish. That's probably why I like svelte :)

csande17• 7 years ago

Svelte has an option to output Web Components, so it might be a good option if you want to use them while still writing your code in a React-y "declarative UI" style.

kjksf• 7 years ago

React, Vue and Svelte solve 2 big problems.

1. components (creating re-usable UI parts (i.e. components) that combine data and their rendering)

2. reactivity - re-rendering UI when data changes.

Web Components only solve one of those problems. And arguably not as well.

sunseb2• 7 years ago

Web components are a great idea, but the current implementation sucks and is a pain to use though. Web components should look like what Svelte did!

Drew_• 7 years ago

"I have learned more HTML5 and CSS3 using svelte than any of the other frameworks because it encourages you to use it, because the wheel has been invented already."

This really doesn't make any sense. Not learning how to effectively use HTML and CSS doesn't have anything to do with what frontend framework you're using.

tekkk• 7 years ago

You make good points but your comment doesnt appeal to me that much. I dont really care about React adding hidden boilerplate for me, as long as it is efficient enough and enables me to work on more productive things. Svelte sounds good, dont get me wrong but the abstractions are there for a reason. We as humans want to minimize complexity and mental overhead having to figure every best practise on our own. Enabling developers to do whatever they want with a framework sounds frankly like a bad idea.

But if svelte can do both, eliminate the boilerplate and at the same time minimize the cognitive burden of having to work with DOM, then im interested. But i rarely have noticed that React makes me angry the way it used to. So do i want to switch, like the stereotypical frontend hipster, to another hype framework and code the next customer app with it? I'll need a lot more convincing first

simplify• 7 years ago

How does svelte get "completely out of your way" when you have to learn its non-standard, framework-specific idioms? bind:value, #each, :catch, #await, x as y, $ prefix, slots, use: ... these all seem like reimplementations of plain JavaScript.

If you're going to go this far, why not use Marko.js and get SSR streaming built in?

Rotareti• 7 years ago

The svelte examples kept me interested until I reached the logic section [0]. Coming from JSX/TSX svelte's template language is a huge downer for me.

https://svelte.dev/examples#if-blocks

vfc1• 7 years ago

I just prefer batteries-included and fewer decisions. Angular already compiles components at build-time using the Angular CLI, and the new upcoming (November) Ivy engine is going to produce bundles that will rival in size with any framework.

The webpack build that the Angular CLI uses internally is completely transparent, you don't have to know Webpack at all. Just do ng build --prod and you have your optimized bundles will all the bell and whistles.

Webpack is even going to be replaced by Bazel but we won't even notice it, all we have to do is ng update and live goes on the next day after the release.

The Angular ecosystem with the Angular CLI is just so stable and complete, with hardly any API changes in years, it's just a joy to work with. The CLI even integrates with Sass and other CSS processors.

You can really focus on the application, and forget tooling. I think the take of Angular on batteries-included tooling & their take on incremental upgrades are such a huge advantage over other ecosystems, AFIK nothing else comes even close.

izelnakri4• 7 years ago

There is something close, even better, when overall API design/architecture is considered, that is ember.js. Check ember-cli/embroider which angular-cli initially forked from. I give it 1.5 years for ember to pretty much dominate SPA development, In the last two years some people were laughing at me, now Im laughing at them.

davidpolberger• 7 years ago

That appears unlikely:

https://trends.google.com/trends/explore?date=today%205-y&q=...

oldmanhorton• 7 years ago

The fact that ember doesn't integrate natively with typescript means that probably won't happen...

howdydoo• 7 years ago

Our company trialed Ember this year alongside React, Angular, and Vue for a new SPA. Ember was the worst of the bunch:

- It is stringly typed. All over the place you're globally registering names as strings (or worse, using strings that implicitly resolve to filenames). You'll write `store.createRecord('mymodel')` instead of just importing things using standard ECMAScript imports.[1] This means static analysis is out the window, which makes it labor-intensive to find usages or do even simple refactors like renames.

- It leans on global state and object mutation way too much, instead of using functional state updating. This was the way older frameworks like Backbone, YUI, etc worked. Web development is moving away from this paradigm, and for good reason.

- Static typing support is non-negotiable in 2019 (and 2015 for that matter, but I digress). Support in Ember is just not there, and I don't see much promise for the future either. React and Angular have had good support for Typescript and/or Flow for a good 5 years now.

- One high point for Ember: the in-browser testing beat the pants off any of the other frameworks. We ended up going with React/Jest/Puppeteer, but this meant we (meaning, I) had to write 150 lines of boilerplate that Ember gives you for free.

Overall working in Ember honestly felt like being transported back in time by 10 years. I guess if you're a solo dev it's easy to whip up a quick demo that seems fine, but you'll hit the wall very quickly where the project becomes write-only. I think it's unlikely a brand new build system, no matter how fancy, can make up for these architectural problems.

[1] https://guides.emberjs.com/release/getting-started/creating-...

EDIT: I regret taking the time to write this. Should have checked submission history first…

paulddraper2• 7 years ago

The problem I am running into with Angular is there is no middle ground.

On one hand, you can yarn install and ng create and you've got a project.

On the other hand, the largest software company on earth uses it.

In the middle is a wasteland. I've worked with it for years and have been waiting for Google to document to the angular compiler (angular/angular not the angular/angular-cli with a million webpack presets). To this day there remains zero documentation other than source code. https://github.com/angular/angular/issues/29623

ggregoire2• 7 years ago

Angular [...] You can really focus on the application

I don't know about the newest versions but I have to disagree for Angular 1, the framework was so badly designed and overengineered that my team and I had to constantly check the doc to remember how to write x or y or what were the best practices to do z.

React does less than Angular but it's way more intuitive and straightforward. The doc is a one-time read.

forget tooling [...] The webpack build that the Angular CLI uses internally is completely transparent [...] nothing else comes even close

React has create-react-app. Vue probably has something similar. Same for Ember. Last time I had to setup a build pipeline myself was like 3 years ago.

winrid2• 7 years ago

When folks say Angular they aren't including v1. That is called AngularJS.

Also, you still configure webpack for your React app right?

brainzap• 7 years ago

The template syntax is a bit weird. Not sure what would have been better but thats just a gut feeling.

matmo• 7 years ago

So for small apps, the final bundle size is significantly smaller since there's no framework "runtime" code included. What about large apps though?

sunseb2• 7 years ago

Svelte is great. It's a shame we need a framework to do that and that the standard HTML/CSS/JS platform can't do that natively.

wintorez2• 7 years ago

I've never been so excited about a library since the React itself.

Web Development Simplified with Svelte

Related Stories