Live data from Hacker News

Svelte is the most beautiful web framework I've seen

thefutureoftheweb.com

111–120 of 210 posts

Re: Svelte is the most beautiful web framework I've seen

#111
post #77
post #55

Earlier quoted context omitted.

I have pretty much exactly this use case (think trading!). I wrote a couple of hundred lines of vanilla JS. It works fine.

Exactly. Stuff like this is extremely simple to write in vanilla js, with a pointer to each of the dom objects you need to interact with. There's no point in using a framework (but of course you can encapsulate your vanilla js in a component to interface with whatever framework you're using).

Isn't the benefit of React/Vue the shadowDOM and not needing to do full page prints with every change? Honest question, I'm just going off what I hear everyone else saying so the vanilla JS, while the code may be more efficient, sounds less efficient since you'll need to re-print the entire page with every change.

Re: Svelte is the most beautiful web framework I've seen

#112
post #89

Earlier quoted context omitted.

That's a good point. Updating the table might be causing a reflow. Will that prevent updates from causing reflows?

It would certainly reduce it. With table-layout:fixed, the default behaviour is that every cell is the same width as the others. With the normal table layout algorithm it’ll attempt to rebalance as every new cell’s content is added. That makes for a very flexible layout that automatically scales to best fit the content, but have to flush and redo the layout for the whole table every time a column width is calculated…

Fixed dimensions is also good for UX, it would suck trying to read a table changing 10x a second and seeing the columns shifting back and forth.

Re: Svelte is the most beautiful web framework I've seen

#113

Earlier quoted context omitted.

If everyone's busy setting little fires, then "You don't have to join in" is not a very good defense.

How does this compare to a fire? It's a constructive new project. Use it if you want, learn from it if you like, or ignore it if you don't care. You seem to have an axe to grind against JS.

You have misunderstood the point. I'm not saying "stop creating new frameworks". Create anything you want, I don't care.

When I am talking about "settling down", I'm talking about the people that implement real systems for businesses to use. Those people have to make decisions on the technology they're pushing.

If those people can't settle on a stack and keep changing their minds on how to implement a user interface, somebody has to pay for that. This is akin to a "little fire" in a very real sense - it's burning money that could be used otherwise.

So telling me that "I don't have to use it" is besides the point. I don't run the whole show by myself. Developers need to be reasonably comfortable with their stack. If you are using but the whole industry is shifting towards , people will just quit on you.

Re: Svelte is the most beautiful web framework I've seen

#114

Earlier quoted context omitted.

I think it's the reverse. If you write pure functional components, React is very understandable. It's easily testable, you know that you'll have the same output if you pass it the same props. Svelte templates just take us back where we've been, with the twist of compiling the templates, which I believe some templating libraries already did.

React conceptually is very understandable, but understanding what it's actually doing under the hood is not.

You can dive down and learn the inner workings, the same as you can dive down and learn how the svelte compiler works, but it's not needed for either one. Understanding the concept is more important.

Re: Svelte is the most beautiful web framework I've seen

#115

I have a table of 100 rows x 10 columns mostly of numbers which change 10 times a second (think trading). The source data sits in an array of objects. On each update, I need to update the table cells with the latest values from the source array. The content of each cell can change, possibly it's css class too (from red it become blue for example). I'm using Vue/Bootstrap-Vue table at the moment, but it's quite slow.…

No framework can fully eliminate the underlying performance sinkhole that is the DOM. If you have to mutate, you will pay the price, period. The smartest framework can only help you eliminate redundant mutations.

What are alternatives?

Re: Svelte is the most beautiful web framework I've seen

#116

Let the "soap box brigade" commence! I got introduced to Rich Harris via a podcast (not personally), but am a big fan of his perspective on JS. I think we can all agree that; if you don't like Svelte, then fine. If you love JSX/TSX - then great! If you're a Vue person, then awesome - its exactly what makes this community great - the diversity & innovation. Not the soap-boxing antics, polarised opinions & vilification…

Totally agreed that the diversity of technical innovation is how we got here and its fantastic. Hopefully we keep up with more innovations (such as npm alternatives :cough:).

Its easy to see why some folks would get riled up over this crap though. Like, if you don't like React right now, but want to do frontend development professionally, your job prospects get slashed in half or more. Really like Vue? That's awesome! But you might have a small fraction of the options your peers do when interviewing. Like a more exotic solution like Svelte or Elm? Hope you like working remote or are okay with relocating for that, because there's probably not that many places to work at in your area.

So people will try really hard to get the community to rally around their favorite choices. And the tools without cheerleader squads often fade away and die. Rock and a hard place.

Re: Svelte is the most beautiful web framework I've seen

#117
post #77

Earlier quoted context omitted.

Exactly. Stuff like this is extremely simple to write in vanilla js, with a pointer to each of the dom objects you need to interact with. There's no point in using a framework (but of course you can encapsulate your vanilla js in a component to interface with whatever framework you're using).

Isn't the benefit of React/Vue the shadowDOM and not needing to do full page prints with every change? Honest question, I'm just going off what I hear everyone else saying so the vanilla JS, while the code may be more efficient, sounds less efficient since you'll need to re-print the entire page with every change.

> sounds less efficient since you'll need to re-print the entire page with every change.

Huh? No, not at all. As far as I understand, React has algorithms that replace only the html that changed in a dom subtree (and that is called virtual dom, not shadow dom, which is a different concept).

But if you already know exactly what has changed and where to change it in the page, there is no need for more complex algorithms to kick in. Just take the pointer to your div or cell and change the content.

Bottom line: React is written in vanilla Javascript. Can't do better than it.

Re: Svelte is the most beautiful web framework I've seen

#118

Earlier quoted context omitted.

No framework can fully eliminate the underlying performance sinkhole that is the DOM. If you have to mutate, you will pay the price, period. The smartest framework can only help you eliminate redundant mutations.

What are alternatives?

For dynamic content, the only alternative to DOM manipulation is rendering to a canvas element.

Re: Svelte is the most beautiful web framework I've seen

#119
post #91
post #68

Earlier quoted context omitted.

I think svelte compiling to native javascript is lightyears more understandable than whatever the hell react is doing

> whatever the hell react is doing Being JavaScript?

I'm a huge React fanboy, but if you try and step through the React code with a debugger, we're kind of a far cry from the days of Backbone and even Angular. For the common mortal, it has to be treated as a black box. Fortunately, its fairly stable, so it's rare you have to care, but...

Re: Svelte is the most beautiful web framework I've seen

#120

Earlier quoted context omitted.

No matter which framework you describe, this is an iterative approach and will be inefficient. The optimized (or, at least faster) way to handle this would be to have a unique ID attached to a cell and offer a direct callback to it via the data. E.g. the symbol for "GOOG" stored in a hash table, when GOOG updates; call that hash directly: "symbols[symbol].update(data)" then re-render the cell DOM element.

If you update all the data why is this more efficient?

contents _can_ change, not _will_ change. So this approach should update fewer cells per update cycle.
Post reply on HN