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

Show HN: Sapper.js – towards a better web app framework

svelte.technology

Post reply on HN
Print view View original

31–40 of 219 posts

Re: Show HN: Sapper.js – towards a better web app framework

#31

Post by bryanlarsen »

"While it's true that citing 'ecosystem' as the main reason to choose a tool is a sign that you're stuck on a local maximum, apt to be marooned by the rising waters of progress, it's still a major point in favour of incumbents."

Yet the article makes clear that React is working on implementing some similar technologies. Is there anything in svelte / sapper that cannot eventually be implemented in React / next.js too? I'm more than willing to wait a year for it to show up in React rather than live on the bleeding edge...

Re: Show HN: Sapper.js – towards a better web app framework

#32

Post by wcarron »

QGmLe wrote: post #15

An ideal web app framework would not be in JavaScript...

Do you have any other frameworks in mind? Ones that easily and concisely hook into the DOM APIs provided by browsers? One that hot reloads in dev? Or maybe just accomplishes even a handful of the 11 targets listed at the beginning of the article?

Because I don't know of any. Except maybe the new Rust framework, Yew. Which seems very interesting.

Re: Show HN: Sapper.js – towards a better web app framework

#33

Post by breatheoften »

“Compiler as framework” seems like a really terrible unifying vision — a far more interesting framing I think would be “type system as framework”. It’s the difference between “this app is assembled by cobbling together a bunch of random domain specific syntaxes” and “this app was assembled by combining together resources with different well-defined, well-enforced constraints.”

Re: Show HN: Sapper.js – towards a better web app framework

#34

Post by rich_harris »

bryanlarsen wrote: post #31

"While it's true that citing 'ecosystem' as the main reason to choose a tool is a sign that you're stuck on a local maximum, apt to be marooned by the rising waters of progress, it's still a major point in favour of incumbents." Yet the article makes clear that React is working on implementing some similar technologies. Is there anything in svelte / sapper that cannot eventually be implemented in React / next.js too?…

So far, the React team's work is focused on optimising your app code using Prepack (kind of like Angular's AoT compilation, or similar forms of preparsing that have existed in other frameworks for a few years) — you still need React itself.

It's far from clear that it'll ever be possible to compile a React app to something that doesn't need virtual DOM reconciliation, with all that entails.

Re: Show HN: Sapper.js – towards a better web app framework

#35

Post by scottmf »

Touche wrote: post #21
rich_harris wrote: post #14

Earlier quoted context omitted.

The server is only involved when you first hit the page. After that, the client takes care of all the rendering. There is no discrepancy!

There's a discrepancy if the user doesn't see something when the page first renders but then does see it once the JS runs.

Honestly these are solved issues. It’s 2018.

Re: Show HN: Sapper.js – towards a better web app framework

#36

Post by azangru »

whome2 wrote: post #4
Tankenstein wrote: post #2

As always, my main concern with this is traction. Will this be well supported, with a good community, 4 years down the line? I know React will, just because of the massive amounts of business depending on it. When building something real, i have to think about this because i need to be able to hire developers and actually develop my product instead of rewriting it. That aside, the idea of svelte is cool, and i'm happ…

Massive amounts of business were also built on Angular 1.x but it is no longer supported. To be honest, I am tiring of seeing a new javascript framework everyday. I am pretty sure I saw a post for something called StimulusJs in the last hour and now this.

Stimulus.js is first and foremost for Rails devs. Not very interesting for the rest of us.

Re: Show HN: Sapper.js – towards a better web app framework

#37

Post by RobertRoberts »

rich_harris wrote: post #23
DougWebb wrote: post #18

Sorry, I couldn't resist. Second and third paragraphs, with some minor editing: HTML is close to this ideal. If you haven't encountered it yet, I strongly recommend going through the tutorials at https://www.w3schools.com/html/ . HTML introduced a brilliant idea: all the pages of your app are files in a your-project/pages directory, and each of those files is just an HTML page. Everything else flows from that breakth…

If you don't mind reloading the entire page on every single navigation, and don't have any dynamic data or interactivity, this is indeed a very solid approach.

But this is where the entire argument of "do first page load server side because it's faster" doesn't make any sense.

Because then aren't you suggesting that after that, all the other pages can be slow?

The worst sites I visit now are React.js like sites, instead of the page load being slow, _everything_ is slow. Ugh. I can't wait until web 3.0 and this silly balogna with the "make a browser with React and run it inside a browser" fades out...

(note, Netflix _removed_ their js rendering from their home page cause it was slow)

Re: Show HN: Sapper.js – towards a better web app framework

#38

Post by dfabulich »

Touche wrote: post #6

I think this premise is wrong: > 2. As a corollary, your app's codebase should be universal — write once for server and client This is a mistake a lot of developers make. The server and client are not the same. As far as rendering HTML goes, the client does a superset of what the server does. This means either the framework has to be without leaks; meaning you never need raw DOM access at all, OR it means once you do…

You really want multiple layers of "server" code, one of which is a tweaked version of what's on the client, and one of which is purely server-side.

For example, you can't trust client-side code for security/authentication purposes. You almost certainly don't want client code to connect directly to your database and run arbitrary queries/look-ups. So some kind of server-side-only wrapper around your DB, at least, is required.

But the reason you'd run "client" code on the server is to have a layer of universal HTML-rendering code. The server needs to do it for fast initial page loads (and SEO), and the client needs to do it for fast, offline page loads.

At the same time, there's a bunch of code that will run on the client side only, e.g. click handlers, animations, etc. There's essentially nothing for that code to do on the server, but I think it's still basically correct to call it "universal" when you mean "client code that can also run on the server" which is what Sapper provides.

Re: Show HN: Sapper.js – towards a better web app framework

#40

Post by RobertRoberts »

hluska wrote: post #5
whome2 wrote: post #4

Earlier quoted context omitted.

Massive amounts of business were also built on Angular 1.x but it is no longer supported. To be honest, I am tiring of seeing a new javascript framework everyday. I am pretty sure I saw a post for something called StimulusJs in the last hour and now this.

Sorry, but that isn't correct. Angular 1.x had a release just over a week ago. 1.6.8 was released on December 21, 2017. https://code.angularjs.org

I think he is implying that since Angular 2 is out, 1 is guaranteed to be gone, and no longer supported in the future.

Who would intentionally use an older version of a framework, where the upgrade path breaks compatibility?

Angular 1.x is in essence, dead. It's just going to take a long time to go away.

Post reply on HN