Show HN: Sapper.js – towards a better web app framework • Hacker News Board

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

#121

Post by dbbk » Tue, Jan 02, 2018, 7:46 PM UTC

alkonaut wrote: post #112

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…

I’m not sure I’d share a lot of code between server and client even if I could, but sharing the odd domain type, some utilities etc might be handy. The universalness I want is that I want one language, package manager, toolchain, IDE etc for all the code I’m working on. Worst case would be to have the two platforms being slightly different. Say two IDE’s with slightly different shortcuts, two curly brace languages wi…

Why's that? Why would you want your server response and your client-side app to be different?

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

#122

Post by megaman22 » Tue, Jan 02, 2018, 7:47 PM UTC

OJFord wrote: post #88

megaman22 wrote: post #48

Earlier quoted context omitted.

Possibly a lot of HN has been around the block for a couple of decades at this point, and has seen this web dev stuff come full circle several times, and before that, the same ideas in desktop software. Computer science programs really need to introduce something like a "History of Computing Ideas" course as a mandatory element. Maybe we can get away from rehashing the same cycle of trends every five years and move o…

> 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 command line utilities; make, sed, grep, etc.  They are battle-tested, use them, don't rewrite them a dozen times in JavaScript
    - Here is the progression of version control tools that people have used over time, and some reasons why we've moved on from SourceSafe and rcs to Git.
    - Here's the history of how people have done databases, flat-file, vs sql vs nosql
    - etc, etc, etc.

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

#123

Post by dsego » Tue, Jan 02, 2018, 7:48 PM UTC

wcarron wrote: post #32

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.

This ideal framework would probably work in an ideal browser, without the DOM. Doug Crockford put it nicely, today's browsers are a "vast source of incompatibility, pain and misery".

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

#124

Post by mlsarecmg » Tue, Jan 02, 2018, 7:49 PM UTC

pwaai wrote: post #109

How many of you actually built a React/Redux stack SPA that actually came anywhere near what Sapper offers? The file size problem is underrated. Not everybody walks around with 5G like in South Korea. Not everybody has the latest and greatest Samsung or Apple phone. It's a big problem when you advertise PWA as quick and fast but then in tiny letters mention its using the best case on best network and best phone. If y…

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 never been the problem in the first place. The problem is and has been the dom and the single threaded handling of it.

Fiber will allow apps to schedule. Imagine an app with 100.015 rows that Svelte renders in, say, 500ms, let it be 10ms faster than React 15's 510ms. It would still eat into your frame budget and cause heavy jank like all web apps do. Fiber just wouldn't render the 100.000 rows that don't fit your phones screen finishing the whole op under a single ms. It culls and prioritizes similar to how virtual lists operate in general, but you get that as a first class primitive being able to defer any render call of lesser importance without causing visual distortion or code complexity.

Not to mention that with React you could actually produce a real native app, while redux would allow you to share most of your code. With something like react-native-web you could even write a universal app being able to render both in the web and natively.

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

#125

Post by tootie » Tue, Jan 02, 2018, 7:52 PM UTC

dfabulich wrote: post #38

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…

This has a name and it's the BFF pattern (backend for frontend). It's main reason for existence is just to do SSR. It might also do some level of service orchestration where it pulls API responses from multiple microservices and munges them into a single page model to reduce round trips from the client.

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

#126

Post by alkonaut » Tue, Jan 02, 2018, 7:54 PM UTC

dbbk wrote: post #121

alkonaut wrote: post #112

Earlier quoted context omitted.

I’m not sure I’d share a lot of code between server and client even if I could, but sharing the odd domain type, some utilities etc might be handy. The universalness I want is that I want one language, package manager, toolchain, IDE etc for all the code I’m working on. Worst case would be to have the two platforms being slightly different. Say two IDE’s with slightly different shortcuts, two curly brace languages wi…

Why's that? Why would you want your server response and your client-side app to be different?

Why is what? Why I would not share code?

Server response, do you mean in the context of a server that does server side rendering? I was thinking in the context of a normal app: api backend and (possibly multiple) front end rendering apps

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

#127

Post by innocentoldguy » Tue, Jan 02, 2018, 7:54 PM UTC

wcarron wrote: post #32

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.

Perhaps you're right, there may not be one. However, I think the point the OP is trying to make is that JavaScript is a shitty language and it would be better to invest some effort in replacing it with something better than to continuously try to "fix" all its inherent shitty-ness over and over again to little avail. Sure, JavaScript isn't as shitty today as it was 10 years ago, but it still isn't a well-thought-out, well-designed, or consistent language.

For examples of JavaScript's shitty-ness, I'd point to its various function declaration styles and their disparate effects on the code you write, its wishy-washy scoping, namespacing, the number type's precision problem, NaN being a number type, the ambiguity of this, just to name a few.

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

#128

Post by weego » Tue, Jan 02, 2018, 7:54 PM UTC

scottmf wrote: post #42

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…

I feel like a lot of HN is stuck in 2010 and dislikes all of this new web tech because they don’t understand it. This comment is a prime example.

I am willing to concede your pedigree as a developer as necessary but I've been writing all manner of languages and environments since 99 and I'm sorry to say there's no revolution here, no battlefield to die on. It's a poor model that has been tried and abandoned any number of times in my career. The ubiquity of platforms that suit these ideas and developers who think Web development began with node and spas isn't confirmation that every idea is the future.

Moreover, the notion that because FB or whoever went "hmm nothing solves our domain problem, we have the resources to solve it ourselves" that suddenly they solved every domain problem is equally naive. It's likely that people quoting react stacks are solving issues that never existed for them with libraries they don't need.

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

#129

Post by mlsarecmg » Tue, Jan 02, 2018, 7:56 PM UTC

Touche wrote: post #110

mlsarecmg wrote: post #107

Earlier quoted context omitted.

Like typescript, flow or even es-next. An optional DSL that transpiles to pure javascript isn't an obstacle to programming. A string-template with an arbitrary syntax is an obstacle on the other hand.

svelte templates compile to "pure javascript".

All template engines do. JSX doesn't get compiled but transpiled which makes all the difference. Therefore it works with the language, uses latest es-drafts without problems, is 100% typesafe as it can work with other supersets like TS or flow, it also doesn't rely on dependency injection and all the other annoyances.

The biggest reason for me to prefer it: JSX is a simple but elegant solution to a decades old problem. A function signature was all it took to allow it to become cross platform and independent of the browser. A template engine comes at the expense of simplicity and flexibility. It needs so many abstraction and circumventions to function, injecting scope, evals, parsers, foreign syntax ... and for what, it most certainly doesn't make things easier.

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

#130

Post by chaostheory » Tue, Jan 02, 2018, 7:58 PM UTC

dbbk wrote: post #43

chaostheory wrote: post #12

Is there a reason why most Javascript web frameworks, like this one, tend to ignore relational databases? hmm, I don't even see a mention of how to integrate any datastore with Sapper or did I miss something?

> Is there a reason why most Javascript web frameworks, like this one, tend to ignore relational databases? Yes, because these are frontend frameworks and that is a backend concern.

I could be wrong, but this doesn't look like a front end framework.