81–90 of 95 posts
Earlier quoted context omitted.
Infrastructure adapters are becoming table stakes for frontend frameworks.
Which other frameworks have them out of interest? Sounds like a great feature. AFAIK Next doesn’t and it’ll be interesting to see if it gets them given it’s from Vercel. When I tried Remix you had to choose your deployment when initialising a project and it didn’t look trivial to change it, but that was a while ago.
Earlier quoted context omitted.
Angular template syntax is correct HTML syntax. It's nothing like the examples abovd.
https://angular.io/guide/binding-overview Haven't looked at angular since 2015 to be honest, but it still seems like they do weird html stuff to me, such as: {{customer.name}} or Type something: {{customerInput.value}}
Earlier quoted context omitted.
You're telling me on:click={toggle} is nothing like (click)="toggle()"?
it's not. `toggle` is a pointer to a function name and "toggle()" appears to be an expression which is parsed and then executed (scary). you can on on:click={() => toggle()} in svelte which is more similar, but it isn't parsed and executed, it is a pointer to an anonymous function which is directly executed. on:click={toggle()} in svelte would run the function immediately (probably not what you want) and return the r…
has existed since the dawn of JavaScript in Netscape Navigator 2.0 Beta Gold. Your complaint about the syntax is in fact baked into the foundations of the web.
The really exciting thing about svelte is getting rid of the virtual Dom. Having everything just be explicit JavaScript code that modifies the Dom manually makes for really readable code. If you have not tried it, got to the svelte tutorial and look at the output code. It's awesome.
First we were excited for the virtual DOM which is good for batching updates, flexibility, efficiency, etc. But now the cool thing is to get rid of it?
Earlier quoted context omitted.
> Having everything just be explicit JavaScript code This is funny because it's exactly the reason I prefer react
Agreed, I want markup in my logic — not logic in my markup
Centering JS has always been like putting the cart before the horse.
Earlier quoted context omitted.
I disagree. But I am someone who deals with frontend tech sporadically as opposed to spending all/most of my time working on UI. I was excited about svelte, but have found that coming back to my svelte project after a month or two of not using it was arduous because of all the myriad language level things. There are just too many little svelte specific things to keep track of in head. In contrast coming back to a rea…
You can create a shared store and mutate it from any component, not sure what’s missing there.
Svelte is a major improvement on vuejs. It is a pleasure to work with. I can’t stand react / JSX. Highly recommend anyone who preferred vue over react to give svelte a try.
I preferred Vue over Angular. I certainly feel attracted to Svelte. I'm currently finally doing a big React project, and boy, the complexity is spiraling a bit out of control. It's certainly not DRY.
Earlier quoted context omitted.
Or maybe one day people will realize render functions explicitly listening to event emitters is actually a better pattern than implicit reactivity.
I think it is a shame that the Observable proposal [1] still seems somewhat stuck in Stage 1. It's a better idea than just raw event emitters because of composability (if no other reason). Making Observables "first class" could go a long way to unifying a lot of reactivity patterns in various frameworks, in theory at least. To be fair, Observables and especially Observable composition has a rough learning curve and m…
Earlier quoted context omitted.
I disagree. But I am someone who deals with frontend tech sporadically as opposed to spending all/most of my time working on UI. I was excited about svelte, but have found that coming back to my svelte project after a month or two of not using it was arduous because of all the myriad language level things. There are just too many little svelte specific things to keep track of in head. In contrast coming back to a rea…
You can create a shared store and mutate it from any component, not sure what’s missing there.
Last I checked (and things may have changed since) is that svelte didn't support transparent reactivity for deeply nested objects. So something like `$myStore.foo.bar = "baz"` wouldn't trigger a component update, you need to remember to use .set, .update etc. You could assign to local reactive variables but you couldn't assign to stores.
I am sure the library authors made these trade offs thoughtfully, I was just disagreeing with the blanket statement that Svelte is generally a major improvement over Vuejs.
Earlier quoted context omitted.
While this is all technically true, I don't think it's all that helpful a thought process to have when approaching Svelte. Yes, Svelte files are syntactically valid HTML, Javascript, etc, but they have very different semantics. Take the ability to reference functions in HTML - this is simply not possible in normal HTML, where inline event handlers instead are passed Javascript expressions to evaluate. It's definitely…
Click me 100% valid HTML and within "the normal realm of HTML". The event is passed as a parameter to the function. Has been available since the introduction of JavaScript. Predates addEventListener(…) and its ilk by a few years. Yes, "$:" as a labeled break exists outside JavaScript proper. That said, given the rare cases where anyone uses a labeled break and how unlikely that labeled break would be named "$", it se…
Like I said, it's valid HTML, but it doesn't do what you're describing (and you can try it out fairly easily in your browser). The "onclick" handler executes the code string that it's given, working essentially the same way as `eval` or the `new Function("...")` syntax. It does not take a function pointer.
So in this case, the only thing it executes is a variable pointing to a function, which doesn't do anything because the function isn't being executed. You would need to add the function brackets to get any sort of effect.
This is the crux of the issue: Svelte is an additional language that happens to use the same syntax as HTML and JS, just with different (in some cases very different) meanings. You are not just writing "explicit Javascript code", you're writing Svelte code (which in most cases is probably very easy to pick up if you know Javascript, but it's still a different language).
Compare and contrast with, say, Typescript, which is syntactically different from Javascript, but semantically identical - just remove the types, and you have normal Javascript. (In fairness, with old decorators and enums, this isn't quite true, but it holds in general.)
To be clear, I don't think that's saying that one thing is better than the other, or that Svelte is bad because it's a new language or something. I think reactive primitives in Javascript are important, and adding them directly into the syntax of the language is a really clever way of solving a lot of problems in this space. I'm not sure if it's the solution I like the best (I've really enjoyed working with SolidJS signals recently, which provide some of the same ideas with a more typically Javascript-like API), but it's good to see experimentation here.