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

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

#181

Post by natecavanaugh » Wed, Jan 03, 2018, 3:18 AM UTC

Touche wrote: post #13

rich_harris wrote: post #11

Earlier quoted context omitted.

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!

Then you have a server/client difference if the lifecycle hooks change the dom (like a jQuery plugin or something). So you have to figure out what to do on the server.

The client handles the dynamic aspect of time, whether that's event handlers that may be invoked later or animations which may run at some point and for some length of time. The server only needs to handle it's default, but as other commenters mentioned, lifecycle hooks help manage when some logic gets run.

I think it does take some time to think universally, but it's not all confusion and hair pulling.

In fact, it kinda reminds me of writing testable code. You need to separate some concerns, but ultimately, it's a set of conventions that help you get there.

I can tell you, there are plenty of times when even a rule of two isn't worth the maintenance effort that's caused by rendering HTML in two different places.

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

#182

Post by arxpoetica » Wed, Jan 03, 2018, 3:19 AM UTC

lfischer wrote: post #175

cryptica wrote: post #161

Isomorphic frameworks are a bad idea. I'm convinced that any attempt at making a single general-purpose web application framework will fail. I've seen it happen too many times before. SocketStream, Derby, and even MeteorJS which had massive funding and marketing just couldn't do it. NextJS is just the next generation of fools who didn't research the market... Surely we can at least wait for NextJS to go belly up befo…

From what I’ve gathered, both Next.js and Sapper.js are less ambitious than Meteor and Derby. They require to write your own data access code by hand, by making HTTP requests or importing whatever server-side JavaScript libraries you need, while Meteor and Derby tried to provide the same model API on the server and on the client. Maybe the model API (and the fact that you were almost forced into storing everything in…

THIS.

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

#183

Post by felipeccastro » Wed, Jan 03, 2018, 3:21 AM UTC

unclebucknasty wrote: post #170

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…

> 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 look like everyone’s else app”.

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

#184

Post by Silhouette » Wed, Jan 03, 2018, 3:46 AM UTC

aaron-lebo wrote: post #132

weego wrote: post #128

Earlier quoted context omitted.

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

Your comment expresses a really common sentiment, but it also vague and offers no supporting evidence. When was a model like React + Redux (or Elm) used previously, and why did it fail? The combination of factors (browser advances and iteration on existing models) is unlike anything before. This tech stack did not exist in 1999, it did not exist in 2005, and it did not exist in 2012. It is driven by real problems.

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've been identifying specific parts of a display to rerender fully because doing the whole thing was too expensive since the earliest graphical video games.

We've been using markup languages to describe UI layouts declaratively for a long time too.

Adopting similar techniques in browsers was likely as soon as serious front-end coding to build larger client-side web apps became viable, and they have much the same pros and cons now as they did in other UI development before. React and its surrounding ecosystem may have been the first JS libraries to popularise the ideas for a new generation, and IMHO those early versions of React were well done and useful, but let's not pretend the underlying concepts are radical and new in themselves.

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

#185

Post by Silhouette » Wed, Jan 03, 2018, 3:52 AM UTC

scottmf wrote: post #155

RobertRoberts wrote: post #103

Earlier quoted context omitted.

How does that help 1000 visitors to a blog read the blog easier? Not every site is an app, and the apps we do build we already have invested in VanillaJS framework. Do you think React will outlast the VanillaJS framework? ( http://vanilla-js.com/ ) (edit: this is partly a joke comment, fyi)

I understand the joke but JS isn't a framework, it's a language. "No framework" generally means "poorly-written custom framework". Do you have any code samples to share from your vanilla JS apps?

"No framework" generally means "poorly-written custom framework".

That is not generally true at all. It might be true if you've got a very inexperienced and unskilled team of developers who don't know how to build a non-trivial application without the structure that a framework brings. However, there must be millions of developers in the world who do have sufficient skill and experience to do that, and these days plenty of those people work in web development. I imagine they can still remember how to do things like basic software design and using libraries, which have been working since long before any of these modern frameworks existed.

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

#186

Post by megaman22 » Wed, Jan 03, 2018, 3:57 AM UTC

Silhouette wrote: post #185

scottmf wrote: post #155

Earlier quoted context omitted.

I understand the joke but JS isn't a framework, it's a language. "No framework" generally means "poorly-written custom framework". Do you have any code samples to share from your vanilla JS apps?

"No framework" generally means "poorly-written custom framework". That is not generally true at all. It might be true if you've got a very inexperienced and unskilled team of developers who don't know how to build a non-trivial application without the structure that a framework brings. However, there must be millions of developers in the world who do have sufficient skill and experience to do that, and these days ple…

I'm afraid you're being terribly optimistic. I'm not totally sure how many millions of people, in absolute numbers, are even competent developers. Out of those, some are web developers, and some subset of those are doing things without frameworks. That leaves a lot of yahoos.

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

#187

Post by brett40324 » Wed, Jan 03, 2018, 4:08 AM 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.

FWIW, there's Dart, but at the end of the day it's still just JS. This isnt to argue your point either, but one possible answer to the question(s) you bring up.

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

#188

Post by stephen » Wed, Jan 03, 2018, 4:10 AM UTC

rich_harris wrote: post #30

skrebbel wrote: post #29

I've been following Rich's work on Rollup, Svelte and now Sapper with interest and great awe. I truly believe he's onto something. At the same time, if I were designing something like this, I'd use a tool like Flow or TypeScript in a heartbeat. Doing AOT optimization is so much easier when you have type guarantees, I'm sure that once you go deep enough you get into all kinds of little issues that are only issues beca…

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, again AFAICT, all the other JS frameworks take.

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

#189

Post by Silhouette » Wed, Jan 03, 2018, 4:14 AM UTC

megaman22 wrote: post #186

Silhouette wrote: post #185

Earlier quoted context omitted.

"No framework" generally means "poorly-written custom framework". That is not generally true at all. It might be true if you've got a very inexperienced and unskilled team of developers who don't know how to build a non-trivial application without the structure that a framework brings. However, there must be millions of developers in the world who do have sufficient skill and experience to do that, and these days ple…

I'm afraid you're being terribly optimistic. I'm not totally sure how many millions of people, in absolute numbers, are even competent developers. Out of those, some are web developers, and some subset of those are doing things without frameworks. That leaves a lot of yahoos.

Well, yes, there are plenty of incompetent developers too, as there always have been since development broke out of its earliest new-and-specialised-job days.

Even so, the idea that not using a framework automatically means you'll produce some poor imitation instead is laughable. The history of software development is replete with examples of people succeeding without those frameworks. We've built countless UIs that way that were much bigger and more complicated than anyone has ever built with Angular or whatever this week's flavour of JS framework is.

Maybe there are only thousands of developers working in the web industry who could do it rather than millions. I'm not sure that undermines my real point, since you'd only need a handful of decent devs to make and maintain almost any web front-end I've ever seen.

I suspect the true problem is that for various reasons we lose a lot of that experience and skill from the industry far earlier than we should, and then yet another young generation of developers who haven't studied history are doomed to repeat it, badly.

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

#190

Post by aaron-lebo » Wed, Jan 03, 2018, 4:14 AM UTC

Silhouette wrote: post #184

aaron-lebo wrote: post #132

Earlier quoted context omitted.

Your comment expresses a really common sentiment, but it also vague and offers no supporting evidence. When was a model like React + Redux (or Elm) used previously, and why did it fail? The combination of factors (browser advances and iteration on existing models) is unlike anything before. This tech stack did not exist in 1999, it did not exist in 2005, and it did not exist in 2012. It is driven by real problems.

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.