141–150 of 219 posts
Earlier quoted context omitted.
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
Earlier quoted context omitted.
Maybe it's just the documentation that is lacking, but when I've played with Svelte, the API and template syntax feels like a hodgepodge of special cases. For example, what exactly does a tag starting with colon mean? Is it just arbitrary syntax for things that don't fit in? What does a colon in an attribute mean? (i.e., why on:click rather than onclick or onClick or even something simpler like :onClick?) Why is ther…
Colons indicate that something is a directive rather than an attribute — so `on:click` is the `on` directive with the `click` event, and `bind:thing` is the `bind` directive with the `thing` data property. The one place we violate that slightly is with `:foo`, which is shorthand for `foo={{foo}}` (since people dislike the ceremony of passing props down between components, and this makes it easier). {{#if condition}}.…
Earlier quoted context omitted.
Maybe it's just the documentation that is lacking, but when I've played with Svelte, the API and template syntax feels like a hodgepodge of special cases. For example, what exactly does a tag starting with colon mean? Is it just arbitrary syntax for things that don't fit in? What does a colon in an attribute mean? (i.e., why on:click rather than onclick or onClick or even something simpler like :onClick?) Why is ther…
Colons indicate that something is a directive rather than an attribute — so `on:click` is the `on` directive with the `click` event, and `bind:thing` is the `bind` directive with the `thing` data property. The one place we violate that slightly is with `:foo`, which is shorthand for `foo={{foo}}` (since people dislike the ceremony of passing props down between components, and this makes it easier). {{#if condition}}.…
What made you turn away from javascript and into templates?
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…
Earlier quoted context omitted.
>Sudenly everything needs to be SPA, every site needs to load hundreds KBs of scripts just to "be current". Not everything has to be an SPA, but React is 30kb gzipped and Preact et al are in the single digits. >What's the value of being modern if it makes user experience objectively worse? The point is they don’t inherently make user experience objectively worse. >Sure client side render may prevent you from reloadin…
>You probably only notice the poorly-built SPAs because the UX gets in the way. i.e., confirmation bias. Maybe you are too young to remember Youtube before it was turned into a webapp. It was _considerably_ faster. Todays version requires all sorts of odd refreshing bits and pieces. The old one just loaded right away and showed the video. If I was paranoid, I'd think that Google did it on purpose to push Youtube Red…
PS: It downloads that crappy polymer that weights more than 1.5MB... ffs
Earlier quoted context omitted.
Server-side rendering means you get a quick first load. Client-side rendering means subsequent navigations are quick, because there's less data to transfer (maybe a little bit of JSON, maybe nothing at all). Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things!
Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things! The difference between streaming 100kb and 10kb is small when compared to the connection latency itself. Even on a low-end LTE connection (5mbps), 100kb is 20ms, whereas the latency of a cross-country (US) transit is realistically ~50-100…
Earlier quoted context omitted.
Colons indicate that something is a directive rather than an attribute — so `on:click` is the `on` directive with the `click` event, and `bind:thing` is the `bind` directive with the `thing` data property. The one place we violate that slightly is with `:foo`, which is shorthand for `foo={{foo}}` (since people dislike the ceremony of passing props down between components, and this makes it easier). {{#if condition}}.…
That syntax looks arbitrary and frankly, hell to mantain. The cost:benefit ratio of learning all these idioms ("idioms", a huge red flag) doesn't seem efficient at all. I apologize for being blunt, yet I still recognize your work as great for pushing boundaries in web development. What made you turn away from javascript and into templates?
We've basically covered all those idioms in a few paragraphs. There's very little extra stuff to learn. Now if I may be blunt in return, I was converting the React RealWorld implementation to Svelte for the purposes of this post, and there were moments that I spat out my coffee at how absurd some of it was — twice as much code, with some truly bizarre (but idiomatic-to-React) constructs. It's all a matter of perspective and familiarity!
"This framework is 95% ideal, let's build another framework for my personal 5%." This attitude is why we have a hundred different relevant frameworks right now. How about instead of a building a new framework, you contribute to an existing one? You even say that Next is close to what you want... why not help to make it better? Relevant song about this issue: https://www.youtube.com/watch?v=Wm2h0cbvsw8
One of the authors of Next.js here. I want to clarify that all the points against Next.js are virtues! They probably just arise from Rich not being so familiar with it (or not having looked at the examples/ directory extensively: https://github.com/zeit/next.js/tree/canary/examples ) 1. I think this point is trying to say that we don't have special "mask files" inside `pages/`, which is an idea worth exploring. Right…
My criticisms aren't based on misunderstandings, however. Route masking provides flexibility but it really does undermine the ability to navigate a complex app structure — Nuxt.js evidently reached the same conclusion, because they too have dynamic route parameters encoded in filenames.
The my-server-page-only.js results in a 'Cannot read property 'end' of undefined' error for me, because it seems Next can't distinguish between universal and server-only routes. If you have any examples of this working, please do share them!
The Markdown ZEIT documentation is cool, but doesn't really address the problem I was getting at with , which is that your content is likely to come from a database. (Incidentally, Sapper does provide support for , which works exactly the same as .) > On size: the Next.js and React teams are both working towards really interesting solutions to ship only the code that's necessary, without resorting to templating as the main strategy. I'm excited to see where that takes us. My conviction remains that templates will always provide more and deeper optimisation possibilities than JSX, but this is a competition in which ultimately we're all winners.
Earlier quoted context omitted.
Maybe it's just the documentation that is lacking, but when I've played with Svelte, the API and template syntax feels like a hodgepodge of special cases. For example, what exactly does a tag starting with colon mean? Is it just arbitrary syntax for things that don't fit in? What does a colon in an attribute mean? (i.e., why on:click rather than onclick or onClick or even something simpler like :onClick?) Why is ther…
Colons indicate that something is a directive rather than an attribute — so `on:click` is the `on` directive with the `click` event, and `bind:thing` is the `bind` directive with the `thing` data property. The one place we violate that slightly is with `:foo`, which is shorthand for `foo={{foo}}` (since people dislike the ceremony of passing props down between components, and this makes it easier). {{#if condition}}.…
Why not simply use the "correct" ES6 syntax to do the same thing? It's almost identical:
computed: {
hours: ({time}) => time.getHours(),
minutes: ({time}) => time.getMinutes(),
seconds: ({time}) => time.getSeconds()
}