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

191–200 of 219 posts

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

#191

Post by Silhouette »

aaron-lebo wrote: post #190
Silhouette wrote: post #184

Earlier quoted context omitted.

When was a model like React + Redux (or Elm) used previously, and why did it fail? What do you mean "a model like React + Redux"? Programmers have been separating underlying state, rendering and interactions since at least the earliest days of MVC in the '70s. We've been diffing model states to identify changes to act on for as long as we've had explicit isolated state management, which again is several decades. We'v…

Yes, but that's never been attached to a frontend that reaches billions of people. But like you said, those are good ideas, they didn't fail.

Why does the number of people using a UI make any difference to whether the UI does its job well or whether the underlying technologies are appropriate, though? Would any of the arguments for different ways of building UIs change materially if Facebook had a million active users instead of a billion?

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

#192

Post by aaron-lebo »

Silhouette wrote: post #191
aaron-lebo wrote: post #190

Earlier quoted context omitted.

Yes, but that's never been attached to a frontend that reaches billions of people. But like you said, those are good ideas, they didn't fail.

Why does the number of people using a UI make any difference to whether the UI does its job well or whether the underlying technologies are appropriate, though? Would any of the arguments for different ways of building UIs change materially if Facebook had a million active users instead of a billion?

I'm just saying that even with that model before, we never had tech with the reach or capability as we do now, which makes that interesting.

If it was a good model for building UIs in 1970 and it proved itself then, we should be taking advantage of that on the frontend as well, instead of ignoring it.

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

#193

Post by Silhouette »

aaron-lebo wrote: post #192
Silhouette wrote: post #191

Earlier quoted context omitted.

Why does the number of people using a UI make any difference to whether the UI does its job well or whether the underlying technologies are appropriate, though? Would any of the arguments for different ways of building UIs change materially if Facebook had a million active users instead of a billion?

I'm just saying that even with that model before, we never had tech with the reach or capability as we do now, which makes that interesting. If it was a good model for building UIs in 1970 and it proved itself then, we should be taking advantage of that on the frontend as well, instead of ignoring it.

In that case, perhaps our views here aren't so different. I'd agree that React was a relatively rare qualitative step forward in the tools available in web development, precisely because it did bring some ideas and programming styles into the front-end JS community for probably the first time. I just disagree with the idea that this was unlike anything that had gone before, because essentially the same fundamental ideas and programming styles have been used elsewhere in the programming community for a very long time.

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

#194

Post by unclebucknasty »

felipeccastro wrote: post #183
unclebucknasty wrote: post #170

Earlier quoted context omitted.

> HTML is close to this ideal HTML is anything but ideal. In fact, it's the core of the problem where Web applications are concerned. HTML and its kin (particularly CSS) were designed for content-oriented Web pages, not Web applications. Continuing to devise Web-app frameworks that are predicated upon developers wrangling HTML for controls and CSS for layout will lead to more iterations of frustration; only to perhap…

I agree with your view, but I suspect it hasn’t happened yet for a couple of reasons: - every time it was attempted, the generated html/css was terrible (think old ASP Net for example), and maintenance hard. Abstractions only work when they are not leaky - designers, devs and users in general expect to have custom design for everything, rather than standard controls. Something to do with “have a unique brand and not…

>the generated html/css was terrible (think old ASP Net for example)

We've come a long way in tooling, libraries, and in the underlying standards. Technologies like ASP also pre-dated SPAs and were targeted for server-side development; hence make for a poor analogy. Swing would be a more apt comparison, and even Visual Basic.

In general, poor execution in the past is no reason to drop the objective. We've tolerated plenty of bad HTML-based frameworks and years of CSS-quirkiness, yet we keep plugging away at it.

>and maintenance hard

But the actual objective is that you wouldn't hand-maintain the generated code. We're currently so bound to HTML-thinking that it's hard to embrace that notion.

>designers, devs and users in general expect to have custom design for everything

I've heard this. Interestingly, though, we look to tools like Bootstrap and design-motifs like Material, etc., which emphasize uniformity. Also, there's no reason branding can't be applied without directly manipulated CSS. A good component-based library would allow for that and would also allow for the construction of extensible custom components.

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

#196

Post by tribby »

rich_harris wrote: post #149
Rauchg wrote: post #138

One of the authors of Next.js here. I want to clarify that all the points against Next.js are virtues! They probably just arise from Rich not being so familiar with it (or not having looked at the examples/ directory extensively: https://github.com/zeit/next.js/tree/canary/examples ) 1. I think this point is trying to say that we don't have special "mask files" inside `pages/`, which is an idea worth exploring. Right…

Thanks Guillermo. I hope the respect and appreciation I have for the Next team came across in the post. My criticisms aren't based on misunderstandings, however. Route masking provides flexibility but it really does undermine the ability to navigate a complex app structure — Nuxt.js evidently reached the same conclusion, because they too have dynamic route parameters encoded in filenames. The my-server-page-only.js r…

> Nuxt.js evidently reached the same conclusion, because they too have dynamic route parameters encoded in filenames.

nuxt.js applications don't need to rely on filenames for routing. there's a handy nuxt module for this -- https://github.com/nuxt-community/router-module

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

#198

Post by dmitriid »

gedy wrote: post #85
dmitriid wrote: post #65

Earlier quoted context omitted.

Whatever it compiles down to in the end, it's stringly-typed templates with a custom syntax and weird assumptions about code that break everything you know about Javascript: scoping rules, variable declarations etc.

Okay, but JSX is not 'just JavaScript' either - it's a DSL embedded in JS. You could make the same argument that Svelte is 'just HTML' with a script block, style block etc.

Nope. True, JSX is thin XML-like DSL on top of Javascript. However, it uses Javascript everywhere. It never breaks assumptions about scoping, hoisting, where variables come from etc.

You can skip JSX and write `React.createElement` everywhere, and nothing will change. Your code remains Javascript code. Unlike whatever svelte/sapper is. More details in a different comment: https://news.ycombinator.com/item?id=16053685

Nothing about svelte is "just HTML with styles and scripts". It's a yet another custom weird templating language with its own custom magic binding rules and a Javascript-like scripting language which breaks all assumptions about Javascript (methods/properties hoisting, invalid scoping rules, automatic data/variable injection etc. etc. etc.). And it's also just strings everywhere. And magic strings (as in "add $ to tell svelte the property comes from a store").

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

#199

Post by boubiyeah »

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…

Haha yeah. The magic of green threading is so misunderstood: Ok, it no longer blocks your UI thread but it takes AT LEAST as long as before to render (browsers still don't have an API to reliably schedule small chunks of work without also incurring the cost of setTimeout clamping)

So it's not really an improvement for me, your component tree becomes harder to reason about (when does this component renders??), you may see very unwanted progressive rendering where you didn't want to, etc. Many vdom implementations are faster than React, synchronous perfs matter a lot too.

Even the core React maintainers acknowledge this is kind of like an experiment.

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

#200

Post by tnolet »

rich_harris wrote: post #11
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…

In practice, this isn't an issue. Component lifecycle hooks and methods (which is where anything involving raw DOM access or animation takes place) never run on the server — the SSR renderer just generates some HTML for a given initial state. Once you grok that, it's easy. Certainly much easier than maintaining two codebases in parallel!

Is it stranfe that I actually prefer two codebases? I find the hard split (or just client/server architecture) to provide clarity, focus and peace of mind.
Post reply on HN