Earlier quoted context omitted.
Agreed, I want markup in my logic — not logic in my markup
very interesting, i wonder what's your opinion on tools like htmx which work on the exact opposite basis
Svelte is a language
71–80 of 95 posts
Re: Svelte is a language
#72Earlier 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…
I've done a lot of contracting jobs and I get to see a lot of codebases and had the exact opposite experience, Whenever I see react or vue code, and in particular react, I feel like I have to relearn everything because the combination of external state libraries and to top it with translation specific code and libraries makes it such that each code base is very different from the other. It almost feels like you are l…
Re: Svelte is a language
#73Earlier quoted context omitted.
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}}
I agree with you, it looks weird, but my point was that it's correct HTML syntax, even though you cannot expect it to work if you open an Angular template in a browser, but an HTML parser can tell you it's syntactically correct.
Which is completely useless because your website doesn't work anyway
Re: Svelte is a language
#74Earlier quoted context omitted.
Certainly I've had a lot of fun with wiring mobx up to various things that provide render functions (react with mobx viewstate classes is way nicer than hooks to me). Svelte I've never quite got the hang of to the point where I feel comfortable expressing an opinion about it (and I haven't spent enough time experimenting to claim my not having got the hang of it yet means anything either).
Mobx as your ViewModel/Model selector implementation is precisely where it belongs in your stack. You just need to be disciplined and not build your whole state/update loop on it. Sadly, I'm stuck on v4.5.x at work, and my big complaint is arrays not being a first-class observable.
If you have a minute, I'd love you to expand on that. I have some thoughts along those lines myself but I suspect you've spent more time with mobx than I have and would rather hear yours from cold.
(I also keep looking at mobx-state-tree and wondering if that would work for me, I'm not sure I know enough to judge what the trade-offs involved are particularly well)
Re: Svelte is a language
#75Svelte Kit is great for static is "classic"-like websites. I've converted my company website to svelte-kit from first Angular, then Vue. But for SPA it's bad. If you use oidc auth. There's only Auth.JS and it's a confidential client, for Svelte Kit. If you're not using svelte-kit you can use vite to create a Svelte SPA. There you can use your PCKE client as usual and burden the load on the client. I have yet to exper…
Re: Svelte is a language
#76Svelte 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'm currently finally doing a big React project, and boy, the complexity is spiraling a bit out of control. It's certainly not DRY.
Re: Svelte is a language
#77Re: Svelte is a language
#78Svelte 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 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…
Re: Svelte is a language
#79Earlier quoted context omitted.
> I don’t follow… in what sense is this JavaScript? > it's not. it's html. incrementCount is a pointer to a javascript function. > Or what about this… is this JavaScript? > $: doubled = count * 2; Yes. $: is a javascript label. We use it to indicate that a function should be reactive - if the count variable changes, the right hand will be rerun and double updated. > Click me html again. the |once is a modifier to cli…
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…
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 seems a pretty safe extension to the language to allow such powerful behavior.
Both "$:" and "$store" are not magical; they are quite deterministic and serve to substantially reduce the total amount of boilerplate. Seems a fair tradeoff, but you are correct, it's a superset of the JavaScript language.
Now let's discuss the "naturalness" of useState, useMemo, and their ilk. I'll take Svelte's minimal "magic" over the verbose, repetitive, and error-prone library API logic, thank you very much.
Re: Svelte is a language
#80Earlier quoted context omitted.
> I don’t follow… in what sense is this JavaScript? > it's not. it's html. incrementCount is a pointer to a javascript function. > Or what about this… is this JavaScript? > $: doubled = count * 2; Yes. $: is a javascript label. We use it to indicate that a function should be reactive - if the count variable changes, the right hand will be rerun and double updated. > Click me html again. the |once is a modifier to cli…
> which the compiler picks up I think this is the crux of the gp's question. The browser doesn't support explicit behaviours for "on:click" or "|once" (the "$" label is a cool trick I'd forgive the gp for not recognising as native JS) - it may be "valid" HTML but it's not "just HTML" (nor just JS), it's a DSL.
Anyone who already knows HTML and native event handling could pick this up in less than 5 minutes. Good enough.