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

201–210 of 219 posts

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

#201

Post by OJFord »

megaman22 wrote: post #122
OJFord wrote: post #88

Earlier quoted context omitted.

> Computer science programs really need to introduce something like a "History of Computing Ideas" course as a mandatory element. Isn't that the whole programme? In my final year I had a couple of more advanced courses in which we could just about get our heads around results published by the lecturer four years ago when we started the programme. Everything else is just working up to that, from Boole's ideas; through…

You're looking at this from a more academic perspective than my comment implied. Really, it's the whole clusterf&*^ of software engineering being conflated with computer science, when they are really not the same thing in any way. There is a lot of practical implementation history that people are often woefully ignorant of, and it leads them to tread the same paths over and over and over. - Here are the core GNU comm…

Ah, I see what you mean. Apologies, I didn't mean to digress from the spirit of your comment, I suppose it just varies with experience: of the things mentioned, including web frameworks, I _did_ hear of the history of how people have done databases, but other than that GNU tools are just things I used to get the work done, and I learned git through open source. (Though I think it would make a great 'stuff you've learned put into practice' talk: diff algorithms, data structures, etc.)

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

#202

Post by Tankenstein »

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.

As far as i know, even though it was the hype at the time, angular 1's traction was not quite that of react's. All of the FB family (messenger, instagram, fb etc), including the apps are on it. AirBnB is on it (including the apps), Uber's on it, etc. That kind of business gives me peace of mind. Angular 1 wasn't used in large google apps, as far as i know most of them are still gwt.

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

#203

Post by mlsarecmg »

leeoniya wrote: post #169
mlsarecmg wrote: post #124

Earlier quoted context omitted.

You can boil down react to virtually nothing. preact-compat turns it into 4kb. Redux + router don't add that much. The loading impact, if you watch out, code split, isn't the dire problem. As for laggy experience, Fiber is the only feasible attempt at the moment to actually tackle it. Microbenchmarks will not help and neither Svelte nor anything else will make a webapp fast on a slow phone as baseline diffing has nev…

> Imagine an app with 100.015 rows i can imagine an app like this. and such an app would have been designed with 0 thought given to the actual usability by humans. the proper solution is to provide sorting, grouping, filtering and pagination. your UIs should be small enough to remain fast without insane optimization tricks. mobile and even desktop browsers are plenty slow at rendering/reflowing 100k DOM nodes; the fa…

The list is an example, the cheapest one to make it understandable. Let it be 2000, or 100, filtered and pre-processed. It would still take longer than the 15 the user actually sees. The point isn't the list, but the primitive.

I don't even know where the scepticism comes from, culling and priotization is normal on the desktop. You've been offloading UI related tasks that could interrupt animations or interactions in C# forever - it is a great tool to have and getting it for the web is a major step. Microbenchmarks that measure baseline deletes/adds/changes will simply not result in apps that feel native. Thinking framework xyz will just feel acceptable to mobile users because Krausest says it takes 1ms less adding 100.000 rows, that is just silly.

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

#204

Post by GordonS »

mlsarecmg wrote: post #203
leeoniya wrote: post #169

Earlier quoted context omitted.

> Imagine an app with 100.015 rows i can imagine an app like this. and such an app would have been designed with 0 thought given to the actual usability by humans. the proper solution is to provide sorting, grouping, filtering and pagination. your UIs should be small enough to remain fast without insane optimization tricks. mobile and even desktop browsers are plenty slow at rendering/reflowing 100k DOM nodes; the fa…

The list is an example, the cheapest one to make it understandable. Let it be 2000, or 100, filtered and pre-processed. It would still take longer than the 15 the user actually sees. The point isn't the list, but the primitive. I don't even know where the scepticism comes from, culling and priotization is normal on the desktop. You've been offloading UI related tasks that could interrupt animations or interactions in…

I would think that some combination of sorting, grouping, filtering and pagination would still make for a more user-friendly experience.

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

#206

Post by purerandomness »

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.

If you get wouldn't you want that?

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

#207

Post by vitro »

rich_harris wrote: post #53
RobertRoberts wrote: post #37

Earlier quoted context omitted.

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 ins…

Server-side rendering means you get a quick first load. Client-side rendering means subsequent navigations are quick, because there's less data to transfer (maybe a little bit of JSON, maybe nothing at all). Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things!

You know, we may be to specialized to see that normal users that are in majority do not care. Of course you may argue that page load and responsiveness is important in regard to the conversion metrics, be it so, but imagine some average non IT person. Your mother in her seventies. A high school friend. Your auntie. Do you think they care what technology is used? Certainly not. I've seen sites that you would label ugly and from 2000's, but they just work, users can use them easily. And I have seen a rewrite of such old site to modern js framework and it was a disaster, owner was sued by users of the site as they were missing profits because the site was slow and cumbersome.

I think the question is, who do you write the site for, for others or to satisfy your ego and show off?

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

#208

Post by mlsarecmg »

GordonS wrote: post #204
mlsarecmg wrote: post #203

Earlier quoted context omitted.

The list is an example, the cheapest one to make it understandable. Let it be 2000, or 100, filtered and pre-processed. It would still take longer than the 15 the user actually sees. The point isn't the list, but the primitive. I don't even know where the scepticism comes from, culling and priotization is normal on the desktop. You've been offloading UI related tasks that could interrupt animations or interactions in…

I would think that some combination of sorting, grouping, filtering and pagination would still make for a more user-friendly experience.

I don't think there's anything more user unfriendly and annoying than pagination. Pull/click/scroll to load have been made to help it. But that aside, the list isn't important. It could be dialog items, complex tree-views, plugins, graphs, visuals in general, etc.

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

#209

Post by rich_harris »

stephen wrote: post #188
rich_harris wrote: post #30

Earlier quoted context omitted.

Thank you. Svelte itself is written in TypeScript so I'm a believer. I'd like to get first-class support for TypeScript in components at some point. Adding .ts support for the non-component parts of a Sapper app should be fairly straightforward (it's just a webpack config after all) — will add that to the TODO list.

Curious, but since you're a TypeScript believer, and venturing into "build yet another JS framework", why not make it TypeScript-first or even TypeScript only? Granted, you'd loose a large number of JS-only potential users, but seems like it'd be very differentiating (and unique?) to be TS-first, and market/specialize within the large niche of TS developers/teams. Vs. the usual TS-last/TS-kinda-sorta approach that, a…

Learning a new framework is intimidating enough without potentially having to learn a new language on top of it. I work in the news business, among people who in many cases learned the bare minimum of JavaScript necessary to visualise data and tell interactive stories, so that's my natural constituency — beginner-to-intermediate/casual programmers, most of whom don't even know what TypeScript is.

There are TS-first frameworks, such as Angular, and they're off-putting to people who just want to build something.

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

#210

Post by rich_harris »

jitlerr wrote: post #197

Is there any way to use Sapper.js with React, Vue or anything framework? I find the premise behind Sapper interesting, but I just don't see the appeal of Svelte, where they are basically reinventing HTML syntax.

Svelte is the premise behind Sapper. If you want to use React, use Next; if you want to use Vue, use Nuxt; if you want that 7kb Hello World (instead of Next's 204kb or Nuxt's 175kb) then you have to adopt a more efficient approach.

We're not reinventing HTML, we're using HTML. And CSS. ('Reinventing HTML' is a far more fitting description of JSX, and then there's CSS-in-JS...)

Doing so is what allows us to statically analyse your app and compile it to a) a tiny client-side JS payload, and b) an incredibly efficient server-side renderer.

Post reply on HN