“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.”
Show HN: Sapper.js – towards a better web app framework
81–90 of 219 posts
Re: Show HN: Sapper.js – towards a better web app framework
#82Earlier 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…
Re: Show HN: Sapper.js – towards a better web app framework
#83Earlier 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…
Re: Show HN: Sapper.js – towards a better web app framework
#84Earlier 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.
Re: Show HN: Sapper.js – towards a better web app framework
#85Earlier 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.
Re: Show HN: Sapper.js – towards a better web app framework
#86Earlier 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…
Re: Show HN: Sapper.js – towards a better web app framework
#87Earlier 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…
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
#88Earlier 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…
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
#89Earlier 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.
Re: Show HN: Sapper.js – towards a better web app framework
#90Earlier 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…
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...