21–30 of 219 posts
Earlier quoted context omitted.
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 server is only involved when you first hit the page. After that, the client takes care of all the rendering. There is no discrepancy!
Earlier quoted context omitted.
I think the big benefit here (and most of Rich Harris's projects) is less "will this be the next big thing?" as it is pushing the client-side app world forward with new ideas and questioning status quo. Rich balances these "wild ideas" with solving practical problems and I'm always impressed.
As much as i want to like it, i have troubles thinking of templates as something that questions the status-quo. The other big thing seems to be loading effort, but react has gotten so small (react+react-dom = 29kb, react+react-dom-lite 15kb, preact-compat 4kb), there's not really an impact any longer. And as for performance, could Svelte even approach something like the Sierpinski demo - something that would allow Re…
Ok, I'll level with you — that's not actually doing the same thing as the Fiber version. But that's it's basically impossible to accidentally slow down your Svelte app in the same way as the Fiber demo depends on. Fiber doesn't really speed things up so much as it prevents bad code slowing things down.
The innovation isn't templates (though these aren't your grandad's templates), it's compiling those templates to lean, memory-efficient JS code that doesn't depend on virtual DOM reconciliation or anything like that.
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…
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.
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?
Or serve your data from a different app altogether. There are so many possibilities here, depending on the requirements of your app, that it would be folly for a framework like Sapper to dictate how you solve this problem — instead, it gives you the tools to easily solve it yourself.
If the "compiler as framework" idea sounds interesting to you, and you don't mind a little Scala, this paper might also be of interest to you: https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web...
This really does sound like we're slowly reinventing lisp
An ideal web app framework would not be in JavaScript...
It's fine to hold that opinion, but in order to usefully contribute to this conversation you need to give a concrete reason why.
I think Kotlin is becoming a good choice for these criteria. If you want to follow Mr. Harris's framework as compiler approach, Scala may also be a good choice, because of all the compile-time metaprogramming facilities it has. I don't know how Scala Native stacks up beside Kotlin Native, though, and I've read that Scala 2.12 requires Java 8, so that's probably not a good choice for downlevel Android support.
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 because JS is both dynamic and very quirky.
Rich, if you're reading this, did you consider this and if so, why not?
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…
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.