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

Svelte – A UI framework that compiles into tiny standalone JavaScript modules

svelte.technology

Post reply on HN
Print view View original

121–130 of 236 posts

Re: Svelte – A UI framework that compiles into tiny standalone JavaScript modules

#121

Post by k__ »

andrewvijay wrote: post #86
k__ wrote: post #76

Earlier quoted context omitted.

> If u don't like it you don't have to use it Don't write things like that, it always reads like "Noone cares about your opinion, so stop using X and also stop writing about how bad X is"

Wow. How can someone even understand it like that! No way. I actually meant what I wrote and im not really worried about what someone else might think about my comment. Cause it's way way softer.

Even if someone doesn't like it AND doesn't use it, they can still tell the world how they think about it.

You could have written your comment without that sentence and it would still convey your opinion :)

Re: Svelte – A UI framework that compiles into tiny standalone JavaScript modules

#123

Post by fzaninotto »

The precompilation is a nice idea, but I'm not buying the "vanilla JS" argument. The reason why React and other frameworks have a runtime is also because they optimize rendering.

The Svelte doc says: every call to `component.set()` produces a synchronous DOM update. I can already see how this leads to very poor rendering performance in applications with a large number of nested components.

React and the Virtual DOM solved this problem, and that's why web apps today use a lot of components. So until Svelte can demonstrate fitness and speed comparable to React on large apps, it just looks like Yet Another JS Framework.

Re: Svelte – A UI framework that compiles into tiny standalone JavaScript modules

#124

Post by monfera »

psion wrote: post #102

Why are there complex MVC frameworks that run in the browser in the first place? I might get some flack for this, and I'm prepared for it, but why can't we use JS as just a view manipulator? Leave data processing and business logic to the back-end, on the server, and that can take care of needing a front-end framework and large app.

> Leave data processing and business logic to the back-end, on the server

In general, this is not good. Of course there are specific applications where it's useful but in the general space of applications it would be very limiting.

For example, go to http://square.github.io/crossfilter/ and do the filtering on the 5MB data such that you wait for the histograms to be updated from the server. Instead of the tens of milliseconds, it might be seconds or tens of seconds if the server is loaded, i.e. orders of magnitude slower, not to mention unpredictable.

You can think of the network as a data flow constraint. It constrains latency, throughput, privacy and security; the constraints can be unpredictable (network outage; DoS, MiM attack etc.). There can be many good reasons for wanting part of your domain specific logic to fall on the client side.

In particular, dynamic media e.g. interactive data visualization, games and most interactive things that use data or modeling are best partly in the browser.

We're past the point where the rule of thumb was to do business logic on the server and the client only did the presenting of the view and acted as a controller.

Re: Svelte – A UI framework that compiles into tiny standalone JavaScript modules

#125

Post by mschaef »

k__ wrote: post #29
ryanbrunner wrote: post #27

Earlier quoted context omitted.

Trying to avoid boilerplate is in my experience not about laziness - especially when you consider the extreme lengths a lot of developers will go to to eliminate duplication and boilerplate from their codebases. Copying a Redux reducer that implements a standard set of CRUD actions is lazier in my mind than trying to abstract common patterns away. For me at least, the reason boilerplate bothers me so much is that it…

"the reason boilerplate bothers me so much is that it impacts the readability of my code" But if you hide boilerplate you not really improve readability. Not seeing what is really happening just creates the illusion of readability.

'illusion' and 'readability' are interesting choices for words, given that both refer to how something is perceived.

The argument I'd make is that the illusion is the point when you're writing well abstracted code. The abstraction makes it possible to write code with the assumption that some specific detail is taken care of automatically. While it's true that the detail is hidden, that lets the author and reader of the code focus on other details that might be more important.

Of course, this doesn't absolve anybody from needing to be at least somewhat aware of the abstractions, but hopefully most of the abstractions can fade into the background most of the time. (Anybody who's ever worked with a buggy compiler can attest to how frustrating it can be when this is not the case.)

Re: Svelte – A UI framework that compiles into tiny standalone JavaScript modules

#126

Post by shoq »

bryanrasmussen wrote: post #118
ryanbrunner wrote: post #90

Earlier quoted context omitted.

If the thing that I'm abstracting is routine, and unrelated to the business problem I'm solving, I don't need to know what's happening (at least in the sense of me or someone else coming back to read the code later). I don't need to know how an HTTP server, or the particulars of an AJAX request work most of the time.

true, but when there is something unexpected about how the AJAX request or the HTTP server are working then debugging is going to be harder because of the abstraction.

Is it really? If there is an error it's either the abstraction or the concrete usage it stems from.

Re: Svelte – A UI framework that compiles into tiny standalone JavaScript modules

#127

Post by gildas »

blauditore wrote: post #109

> You can't write serious applications in vanilla JavaScript without hitting a complexity wall. This somewhat annoys me. You can definitely do it. Sure, it's easier, more comfortable, safer and quicker to use something like React. But you can still do some modularization that scales reasonably well without it. I've been working on an app and spent a lot of time looking into frameworks to handle its complexity but end…

I agree. Ten years ago, writing application in vanilla JS was hard because of the browser incompatibilities. Today, browser vendors really do an effort to avoid such issues. Furthermore, today the DOM API is very well documented and, over time, I find it getting easier to learn and use.

Re: Svelte – A UI framework that compiles into tiny standalone JavaScript modules

#128

Post by mvindahl »

fzaninotto wrote: post #123

The precompilation is a nice idea, but I'm not buying the "vanilla JS" argument. The reason why React and other frameworks have a runtime is also because they optimize rendering. The Svelte doc says: every call to `component.set()` produces a synchronous DOM update. I can already see how this leads to very poor rendering performance in applications with a large number of nested components. React and the Virtual DOM s…

Haven't studied the SvelteJS documentation but as far as I can reason there is nothing in their idea that prevents them from shielding the DOM behind a lightweight, virtual DOM, ReactJS style. In fact, I'd be slightly disappointed if they don't shield the DOM somehow. It's the #1 bottleneck, after all.

Re: Svelte – A UI framework that compiles into tiny standalone JavaScript modules

#129

Post by mtrn »

blauditore wrote: post #109

> You can't write serious applications in vanilla JavaScript without hitting a complexity wall. This somewhat annoys me. You can definitely do it. Sure, it's easier, more comfortable, safer and quicker to use something like React. But you can still do some modularization that scales reasonably well without it. I've been working on an app and spent a lot of time looking into frameworks to handle its complexity but end…

> I've been working on an app and spent a lot of time looking into frameworks to handle its complexity but ended up sticking to vanilla JS to keep more control.

On a recent hackathon, I wanted to implement instant search and ended up using mostly plain javascript for this reason. Not pretty, but worked: http://i.imgur.com/lLi3noX.gifv

Re: Svelte – A UI framework that compiles into tiny standalone JavaScript modules

#130

Post by boubiyeah »

fzaninotto wrote: post #123

The precompilation is a nice idea, but I'm not buying the "vanilla JS" argument. The reason why React and other frameworks have a runtime is also because they optimize rendering. The Svelte doc says: every call to `component.set()` produces a synchronous DOM update. I can already see how this leads to very poor rendering performance in applications with a large number of nested components. React and the Virtual DOM s…

I don't know, it could work. React almost does the same thing actually, except it batches updates occuring in a single event handler, but otherwise, there is nothing optimized about it, except the reconciliation. A limited string template makes reconciliation a non problem.
Post reply on HN