[HN Gopher] Svelte is a language
___________________________________________________________________
Svelte is a language
Author : r0xsh
Score : 27 points
Date : 2023-07-11 16:36 UTC (6 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| markeibes wrote:
| If you want a good language that turns into Javascript I
| recommend PureScript
| Tade0 wrote:
| Using the label and block syntax for this was a stroke of genius.
|
| Two great things about this "thinking inside the box" approach
| are:
|
| 1. You're encouraged to use native APIs because they're highly
| unlikely to clash with the framework.
|
| 2. You can a legible stack trace. After all, the only thing the
| compiler does to your JavaScript is add some instrumentation here
| and there.
| amadeuspagel wrote:
| I love the idea of "thinking inside the box". It's a great
| encapsulation of the hacker mindset. A fun talk about it in
| another context (impro theater):
| https://www.youtube.com/watch?v=bz9mo4qW9bc
| turtleyacht wrote:
| > _Svelte is a language._
|
| All Javascript frameworks may become implementations of SAT
| solvers, where rendering and state are scheduled constraints,
| i.e. tiny operating systems.
|
| _NPM uses CSS as a query language_ -
| https://news.ycombinator.com/item?id=33136843 - 9 months ago
|
| Then apps may be instantiations of the framework.
| justin_kempton wrote:
| [dead]
| xrd wrote:
| 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.
| ryan29 wrote:
| I haven't used Svelte beyond a couple toy tutorials, but, for
| me, the infrastructure adapters [1] are the most exciting
| thing. I love the idea of being able to build using Svelte and
| auto-magically deploy to something like Cloudflare Pages
| without completely giving up the potential to deploy somewhere
| else.
|
| 1. https://kit.svelte.dev/docs/adapters
| xrd wrote:
| I've got mixed feelings about this and I'm sure I'm in the
| minority. Those adapters are usually supported by the
| commercial company that wants you to use them. But, for
| example, the static or node adapters often don't work great
| with the important parts of svelte kit like SSR, and feel
| like second class citizens.
|
| I love svelte but I'm having a hard time getting the same
| development ergonomics out of svelte kit. It's probably just
| me.
| gervwyk wrote:
| Great insight. It feels like at some point reactivity as a
| language primitive should be built into js. Most frameworks start
| with this and then build out into a opinionated implementation,
| dissolving the ecosystem into framework fragments. Any known
| reasons why this is / was never implemented?
| paulddraper wrote:
| https://dev.to/this-is-learning/the-evolution-of-signals-in-...
| rcme wrote:
| Or maybe one day people will realize render functions
| explicitly listening to event emitters is actually a better
| pattern than implicit reactivity.
| WorldMaker wrote:
| 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 many frameworks like Svelte
| intentionally prefer implict reactivity and avoiding things
| like explicit Observables because they are seen as too
| complex/"too hard" for the average developer.
|
| (Then you get awful worst of both worlds frameworks like
| Angular that sort of rely on Observables but yet also don't
| trust teaching Observables and wind up with code that isn't
| properly Observable and so _also_ has all the code for
| implicit reactivity _and_ is full of nasty escape hatches
| that cause all sorts of composition problems and unnecessary
| side effects.)
|
| [1] https://github.com/tc39/proposal-observable
| SebastianKra wrote:
| I really, really love Observables as an imperfect solution
| in an imperfect world, but I don't think they will solve
| reactivity.
|
| The main issue is, that it becomes a nightmare to transmit
| and compose meta-information. An example would be the
| fetchStatus of ReactQuery [1].
|
| I way too often end up in situations like this:
| .map { unwrapMetaData ...
| rewrapMetaData } ... .map {
| unwrapMetaData ... rewrapMetaData }
| .switchMap { // unwrap metadata and wrap it in an
| observable combineLatest(...) // have fun juggling
| an array of nested monads :) }
|
| I wonder if it is possible to create a mixture between
| React hooks and async/await. Since you tend to work in one
| big scope, you could ignore the meta-info until you need
| it. async live function() { const {
| value, meta } = observe getValue(...) // suspends when
| loading, throws on error // work with values
| const multipleValues = observe Observe.all(...map(i =>
| ...)) // more work // evaluateMetadata
| }
|
| [1]: https://tanstack.com/query/v4/docs/react/guides/querie
| s#fetc...
| rcme wrote:
| You can already combine hooks with something like Rx
| using the useSyncExternalStore hook.
|
| I've worked on very complex Rx code bases. I like Rx, but
| it gets it be a huge pain the debug when you have very
| complicated chains. I haven't used hooks too much, but
| from what I've seen the default behavior is to "do the
| wrong thing" which makes them very annoying to work with.
| The implementation of hooks is also very hacky. Like you
| can't create a hook inside an if statement. That's crazy.
| WorldMaker wrote:
| I've had some success with writing Async Generator
| functions in mixed RxJS/IxJS pipelines.
| async *function someMapOperation() { const {
| value, meta } = await getValue(...)
| doSomething(meta) yield value for await
| (const { value, meta } of
| AsyncIterableX.from(mergeAll(...).pipe(takeUntil(...))))
| { doSomething(meta) yield value
| } // ... }
|
| (I've done similar things in C#, as well, with its Rx/Ix
| pair.)
|
| You are right, there are still good cases where being
| able to write the "state machine" of a complex flow as an
| async (generator) function makes it a lot easier to
| reason with. The nice thing is that Observables work well
| with AsyncIterables and a pipeline doesn't have to be
| just one or the other.
| mst wrote:
| 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).
| bluefirebrand wrote:
| Event emitters/listeners are entirely too magical and
| borderline impossible to write automated tests for imo.
|
| I don't think that's a good direction to go.
___________________________________________________________________
(page generated 2023-07-11 23:02 UTC)