Live data from Hacker News

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

svelte.technology

81–90 of 219 posts

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

#81

“Compiler as framework” seems like a really terrible unifying vision — a far more interesting framing I think would be “type system as framework”. It’s the difference between “this app is assembled by cobbling together a bunch of random domain specific syntaxes” and “this app was assembled by combining together resources with different well-defined, well-enforced constraints.”

I’m having trouble visualising what you’re hinting at. How do DSLs relate to static typing? Are you referring to writing all code in the same language (as in JSX + JSS)?

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

#82

Earlier quoted context omitted.

It's fine to hold that opinion, but in order to usefully contribute to this conversation you need to give a concrete reason why.

Here's my reason, rooted in practicality and not taste: For me, an ideal app framework would cover both web and native apps. All the major native app platforms rely at least partly on AOT compilation. Android, in particular, is based on a runtime that resembles the JVM at the API level and takes JVM bytecode as input at build time. So for me, the ideal app framework would be in a language that's amenable to compiling…

Have you looked at HaXe?

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

#83
post #49
post #42

Earlier quoted context omitted.

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.

Or it may well be that this "all new web tech" was created by people who do not understand neither web nor HTML. Sudenly everything needs to be SPA, every site needs to load hundreds KBs of scripts just to "be current". What's the value of being modern if it makes user experience objectively worse? Sure client side render may prevent you from reloading the entire page. And who cares that this rerender actually takes…

Agree with you on this. Many (most?) sites work just fine with the time-tested method of server-side rendering. When taking compression and browser caching into consideration, you are typically not sending much data across the wire after the first page load.

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

#84

Earlier quoted context omitted.

>...because there's less data to transfer... The problem is that just the theory, reality if often times different. >Going back to the server for 100kb of HTML and reloading the entire page... This implies that 1) you don't go "back to the server" to load your bit of JSON. and 2) the JSON loaded doesn't require any extra templates, images or more JSON to be loaded. See the problem? It's all assumptions. Another thing…

Ultimately, the proof is in the pudding. Which is faster, when you start navigating around? * https://news.ycombinator.com/item?id=16052558 * https://hn.svelte.technology/item/16052558 Bear in mind that HN itself has a huge advantage over HN clones, yet — for me at least, sitting here — the Sapper version is significantly snappier.

It's not just the initial page load though (although that's essentially similar speed). Navigate through the site, and you shave off seconds at every next click.

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

#85
post #10

Earlier quoted context omitted.

Svelte is not "templates" (i.e. client-side), it compiles to JS modules

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.

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

#86
post #42

Earlier quoted context omitted.

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.

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…

I'm still waiting for my web framework in pure ASM idea to manifest.

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

#87
post #42

Earlier quoted context omitted.

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've been doing webdev since 1999. I've seen all manner of stupid hacks, dumb "best practices" that have come and gone, ridiculous frameworks that became _useless_ because browsers just integrated the features. Flash home screens, table layouts, IE only coding up the wazoo. So, when someone says they have a JS framework that replaces the core of the browser's display, the DOM, my response to that is sigh , this again…

You should learn React and build a simple project with it to understand its real value, which is component-based architecture.

React will likely be around longer than/as long as any framework, but whatever replaces it will use a lot of the same concepts.

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

#88
post #42

Earlier quoted context omitted.

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.

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 Turing's and von Neumann's.

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

#89
post #78

Earlier quoted context omitted.

Ultimately, the proof is in the pudding. Which is faster, when you start navigating around? * https://news.ycombinator.com/item?id=16052558 * https://hn.svelte.technology/item/16052558 Bear in mind that HN itself has a huge advantage over HN clones, yet — for me at least, sitting here — the Sapper version is significantly snappier.

Judging based on the 'load' event they are about the same, or the HN version might be a little bit ( So basically the added complexity gives you the same load time when done extremely well (as Sapper is). In terms of bang for your buck, the service worker is biggest improvement. Which you can implement in your server-rendered app.

What about when you start clicking the links in the nav, or opening other stories and profile pages? As far as I can see, the Sapper version blows the original out of the water.

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

#90
post #42

Earlier quoted context omitted.

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've been doing webdev since 1999. I've seen all manner of stupid hacks, dumb "best practices" that have come and gone, ridiculous frameworks that became _useless_ because browsers just integrated the features. Flash home screens, table layouts, IE only coding up the wazoo. So, when someone says they have a JS framework that replaces the core of the browser's display, the DOM, my response to that is sigh , this again…

> Shadow DOM is around the corner, what then?

Nothing changes. DOM remains a slow monstrosity impossible to code for. For goodness sakes, reading certain properties in a DOM tree causes a full page reflow [1]

To beat virtual DOM frameworks you have to write extremely specific vanilla JS+DOM code that basically ends up doing the same thing: re-using DOM nodes, event delegation etc. See [2]

Shadow DOM was never meant to be an answer to that. Honestly, I have no idea what it was supposed to be an answer to.

[1] https://gist.github.com/paulirish/5d52fb081b3570c81e3a

[2] https://medium.com/@localvoid/how-to-win-in-web-framework-be...

Post reply on HN