Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Svelte’s characteristics that likely contribute most to improved performance

chuniversiteit.nl

Post reply on HN
Print view View original

191–200 of 205 posts

Re: Svelte’s characteristics that likely contribute most to improved performance

#191

Post by its-summertime »

reissbaker wrote: post #164
its-summertime wrote: post #143

Earlier quoted context omitted.

You are right, my reasoning is as follows (though still 100% personal bias). For writing a web server library, like oak or flask or etc etc: First, resources own the methods, methods don't own the resources, so the path comes first, easy enough, its just a string with potentially placeholders whose values need to be shunted down the line Next is the method, for some reason a lot of libraries like to hardcode these? I…

Not sure I follow the first part of what you're saying. For the part where you're describing what's possible or not in TypeScript/JS, though, you're incorrect: You can't do something like title("hi") vs title({attr:123}, "hi") Yes, you can. In JS it's trivial; in TypeScript, you can even do it while preserving type safety. Here's the function in TypeScript: // First define which signatures are allowed function title(…

that part was clarified later, "so you need to have fixed function signatures unless you want to have a lot of bother in implementing things"

I should not have used "can't" at that point, correct

To be more clear, you "can't" have a difference between an arbitrary object and a record, unless you know the type of the object and a way to disambiguate that from a record.

Of course, you "can" have a difference, a record "is" `typeof record === 'object' && Object.getPrototypeOf(record) === Object.getPrototypeOf({})` (At least as long as no one uses plain objects as non-recordy things), but, this isn't something I've ever had to care about in any other language. In some you have multiple dispatch built into the language, in some you can just pass named arguments arbitrarily. Javascript and Typescript are very inflexible in this aspect.

Re: Svelte’s characteristics that likely contribute most to improved performance

#192

Post by torginus »

icemelt8 wrote: post #29
byearthithatius wrote: post #21

The fact this is already outdated by more recent Svelte releases which changed things drastically is exactly my problem with the modern JS space. So fast moving and most of it is still doing JQuery like reactivity. I am probably just not smart enough to get it, but it reminds me of the constant seemingly pointless rewrites I see in companies. Figure out what works and keep it, is that so hard? Why can other languages…

ReactJS is pretty consistent since last 5 years and probably won't be changing for next 5 years.

Honestly React has no excuse for being this slow - this style of immediate gui it uses was championed by video games, and Dear IMGUI is still doing well in that space.

I think it's worthwhile to compare the 2 - I'm sure one of the major contributors of React's slowness is the crazy amount of objects it generates triggering GCs - desugared jsx code turns into building up the React DOM with React.createElement

There's no reason why they couldn't have just done what Imgui did and each createElement would be a function call, that doesn't need to allocate. Considering the js API is not something most devs use, most folks wouldnt mind if it got replaced.

State management is also another issue - considering React has had a compiler due to jsx since the outset, not using that since the beginning to do a little data flow analysis and figure out which piece of state affects what UI elements is just criminal - an further exacerbates the waste in other parts of framework, by running already wasteful code more often than it needs to.

Tbf, they already fixed the compiler issue with the latest React, but only as a reaction to getting destroyed by Svelte on the performance front.

Just goes to show, that if you don't have competition, there's no guarantee positive change will happen on any time scale no matter the resources you throw at the problem.

Re: Svelte’s characteristics that likely contribute most to improved performance

#193

Post by MrJohz »

MrJohz wrote: post #185
jchmbrln wrote: post #123

Earlier quoted context omitted.

This is insightful. I remember thinking after the first generation of SPA frameworks like Backbone and Ember and—somewhat later—AngularJS that maybe the second generation (React, Vue, etc.) would get it all sorted out and we'd arrive at stability and consensus. But that hasn't happened. The next generation was better in some ways, worse in a few, and still not quite right in many others. Of course I hear plenty of pe…

> [...] we'd arrive at stability and consensus. Honestly, that's basically happened, but just a generation later. Most modern frameworks are doing very similar things under the hood. Svelte, SolidJS, and modern Vue (i.e. with Vapor mode) all basically do the same thing: they turn your template into an HTML string with holes in it, and then update those holes with dynamic data using signals to track when that data cha…

To egotistically comment on my own comment (unfortunately I can't edit any more):

This is all specific to frontend stuff, i.e. how do you build an application that mostly lives on the client. Generally, the answer to that seems to be signals* and your choice of templating system — unless you're using React, then the answer is pure render functions and additional mechanisms to attach state to that.

Where there's more exploration right now is how you build an application that spans multiple computers. This is generally hard — I don't think anyone has demonstrated an obvious way of doing this yet. In the old days, we had fully client-side applications, but syncing files was always done manually. Then we had applications that lived on external servers, but this meant that you needed a network round-trip to do anything meaningful. Then we moved the rendering back to the client which meant that the client could make some of its own decisions, and reduced the number of round trips needed, but this bloats the client, and makes it useless if the network goes down.

The challenge right now, then, is trying to figure out how to share code between client and server in such a way that

    (a) the client doesn't have to do more than it needs to do (no need to contain the logic for rendering an entire application just to handle some fancy tabs).
    (b) the client can still do lots of things that are useful (optimistic updates, frontend validation, etc
    (c) both client and server can be modelled as a single application as opposed to two different ones, potentially with different tooling, languages, and teams
    (d) the volatility of the network is always accounted for and does not break the application
This is where most of the innovation in frontend frameworks is going towards. React has their RSCs (React Server Components, components that are written using React but render only on the server), and other frameworks are developing their own approaches. You also see it more widely with the growth of local-first software, which approaches the problem from a different angle (can we get rid of the server altogether?) but is essentially trying to solve the same core issues.

And importantly here, I don't think anyone has solved these issues yet, even in older models of software. The reason this development is ongoing has nothing to do with the web platform (which is an incredible resource in many ways: a sandboxed mini-OS with incredibly powerful primitives), it's because it's a very old problem and we still need to figure out what to do about it.

* Or some other reactivity primitive or eventing system, but mostly signals.

Re: Svelte’s characteristics that likely contribute most to improved performance

#194

Post by cheema33 »

weinzierl wrote: post #42
cheema33 wrote: post #31

Earlier quoted context omitted.

> I'm no longer a fan of using any front-end libraries at all en lieu of just using standard event listeners and web components You can get away without using frontend frameworks for small and simple projects. However, for large and complex projects you will struggle. For example, try building Google Docs without a frontend library. You will struggle even if you have an army of developers at your disposal. In fact, w…

"For example, try building Google Docs without a frontend library. You will struggle [..]" Except that Google Docs is not built with a framework. At least not a generic one and being generic is kind of the hallmark of framework.

> Except that Google Docs is not built with a framework.

It is most certainly built with a framework. It is just an internal framework.

Re: Svelte’s characteristics that likely contribute most to improved performance

#195

Post by cheema33 »

wiseowise wrote: post #108
cheema33 wrote: post #31

Earlier quoted context omitted.

> I'm no longer a fan of using any front-end libraries at all en lieu of just using standard event listeners and web components You can get away without using frontend frameworks for small and simple projects. However, for large and complex projects you will struggle. For example, try building Google Docs without a frontend library. You will struggle even if you have an army of developers at your disposal. In fact, w…

> You can get away without using frontend frameworks for small and simple projects. Small and simple projects like checks notes VSCode, Obsidian, Min (browser).

I don't know about others, but VSCode uses other libraries and tools to build on top of. It uses Electron, Monaco editor, Web components etc. It is not pure javascript/typescript.

Re: Svelte’s characteristics that likely contribute most to improved performance

#196

Post by weinzierl »

cheema33 wrote: post #194
weinzierl wrote: post #42

Earlier quoted context omitted.

"For example, try building Google Docs without a frontend library. You will struggle [..]" Except that Google Docs is not built with a framework. At least not a generic one and being generic is kind of the hallmark of framework.

> Except that Google Docs is not built with a framework. It is most certainly built with a framework. It is just an internal framework.

Internal or external doesn't matter. The question is if it's used for more than one product - if not, then I'd argue it is not a framework.

And, yes, Google has internal JS frameworks, but I am not aware that GoogleDocs is based on one.

Re: Svelte’s characteristics that likely contribute most to improved performance

#197

Post by masfuerte »

fancyswimtime wrote: post #70
nawgz wrote: post #51

Earlier quoted context omitted.

This is quite a large set of things to hand wave away with no additional justification. Makes it sound more like personal bias than meaningful insight

it feels like a fad to hate on js and js frameworks; esp from people who parrot what others are saying without any actual insight

A fad? People have been pointing out flaws in js for about thirty years. That's long enough to have become a tradition.

Re: Svelte’s characteristics that likely contribute most to improved performance

#198

Post by sixtyj »

jslaby wrote: post #105
sixtyj wrote: post #59

Earlier quoted context omitted.

Yes, don’t tell me this. I have to rewrite PHP based website because a framework doesn’t work with new PHP anymore. Back compatibility sucks in many software.

It must be a pretty old framework if it doesn't work with new PHP.

12 years old untouched framework (Nette). It worked with PHP 5.4 but as hosting provider switched to PHP 8, I’d rather pay extra fee for 5.4 and slowly rebuild site to 8, because there are so many things you probably need to change… This is the reason why Fortran or COBOL people are so valued for banks…because you want continuity not breakups.

Re: Svelte’s characteristics that likely contribute most to improved performance

#199

Post by gkiely »

l1ng0 wrote: post #155
lukev wrote: post #113

Earlier quoted context omitted.

I guess you and I define "actual churn" differently.

I came across an old graphics project I'd made for Windows/DOS around 20 years ago. Within about a half hour I was able to compile and run it on a Linux machine with Wine, installing the latest version of the compiler and dependencies. I can rarely get a 6-month-old JavaScript web project to compile and run this easily. Churn in node versions, npm/yarn versions, dependencies being abandoned, superseded, dropping back…

A HTML page, web components and no build process solves this.

Pinned package versions in npm solves this.

If you want to use the latest dependencies then yes there is ongoing management required. There are tools to help with this.

Re: Svelte’s characteristics that likely contribute most to improved performance

#200

Post by dwaltrip »

gitaarik wrote: post #179
dwaltrip wrote: post #67

So what’s the deal with svelte runes and maybe causing people to switch off of it?

It's just a new way of using reactive vars, which you have to get used to a bit, and which people that don't like change are annoyed about. But it's ultimately a more consistent and flexible way which actually makes a lot of sense once you're used to it.

Thanks for the reply! I’m kind of curious to try out svelte, and that is helpful info
Post reply on HN