20 ms·

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

• Tankenstein 9y ago
  As always, my main concern with this is traction. Will this be well supported, with a good community, 4 years down the line? I know React will, just because of the massive amounts of business depending on it. When building something real, i have to think about this because i need to be able to hire developers and actually develop my product instead of rewriting it. That aside, the idea of svelte is cool, and i'm happy they're continuing to build on that. Excited to see what comes out of this!
  • gedy 9y ago
    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.
    • mlsarecmg 9y ago
      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 React to finally breach the gap between native and web performance? When look at fiber and react-reconciler, it seems to me react is already contemplating the future. The reconciler especially.
      • gedy 9y ago
        Svelte is not "templates" (i.e. client-side), it compiles to JS modules
        • dmitriid 9y ago
          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.
          • gedy 9y ago
            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.
            • mlsarecmg 9y ago
              Like typescript, flow or even es-next. An optional DSL that transpiles to pure javascript isn't an obstacle to programming. A string-template with an arbitrary syntax is an obstacle on the other hand.
              • Touche 9y ago
                svelte templates compile to "pure javascript".
                • mlsarecmg 9y ago
                  All template engines do. JSX doesn't get compiled but transpiled which makes all the difference. Therefore it works with the language, uses latest es-drafts without problems, is 100% typesafe as it can work with other supersets like TS or flow, it also doesn't rely on dependency injection and all the other annoyances. The biggest reason for me to prefer it: JSX is a simple but elegant solution to a decades old problem. A function signature was all it took to allow it to become cross platform and independent of the browser. A template engine comes at the expense of simplicity and flexibility. It needs so many abstraction and circumventions to function, injecting scope, evals, parsers, foreign syntax ... and for what, it most certainly doesn't make things easier.
            • 9y ago
      • rich_harris 9y ago
        You mean this Sierpinski demo? http://svelte-sierpinski.surge.sh/ http://svelte-sierpinski.surge.sh/ 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.
        • mlsarecmg 9y ago
          The whole point is the artificial slowdown. Taking it out makes it meaningless, it prints a few blue bubbles. Scheduling is and always will be the biggest bottleneck. It is that kind of innovation that keeps react relative. As for a lean dom representation, i have never seen or heard of memory related problems regarding v-dom. And won't byte-code make it leaner in any case? React-compiled is already being tested.
          • vanderZwan 9y ago
            "lean" is not limited to memory though - walking down the vdom reconciliation tree can incur get some pretty large overheads in terms of nested JS calls, just to decide that only a few buttons have to change. PureComponents and things like that are meant to help with this, but it still can take quite a bit of engineering effort to get this right. Mind you, I don't actually know if Svelte avoids this problem, but a statement like "doesn't depend on virtual DOM reconciliation or anything like that" kind of implies that it defaults to less work.
    • jondubois 9y ago
      Oh yeah I forgot to factor in the irrefutable fact that Rich is a genius and everyone else who tried building a full stack framework before him was an idiot.
  • whome2 9y ago
    Massive amounts of business were also built on Angular 1.x but it is no longer supported. To be honest, I am tiring of seeing a new javascript framework everyday. I am pretty sure I saw a post for something called StimulusJs in the last hour and now this.
    • hluska 9y ago
      Sorry, but that isn't correct. Angular 1.x had a release just over a week ago. 1.6.8 was released on December 21, 2017. https://code.angularjs.org https://code.angularjs.org
      • RobertRoberts 9y ago
        I think he is implying that since Angular 2 is out, 1 is guaranteed to be gone, and no longer supported in the future. Who would intentionally use an older version of a framework, where the upgrade path breaks compatibility? Angular 1.x is in essence, dead. It's just going to take a long time to go away.
    • azangru 9y ago
      Stimulus.js is first and foremost for Rails devs. Not very interesting for the rest of us.
      • digitaltrees 9y ago
        You can use it with Turbolinks without rails. I have seen elixir and laravel devs using Turbolinks, not sure if they will adopt stimulus too but I suppose they could.
    • digitaltrees 9y ago
      Actually the nice thing about stimulus is that it is deliberate in ignoring the hype cycle. It works with Turbolinks and rails core to add the small but missing interaction from a traditional ssr framework.
    • Tankenstein 9y ago
  • nailer 9y ago
    I think I've been using Rixh's previous project, Ractive, onr of the first virtual DOM implementations, for 4 years now. It has a decent community and good stack overflow love.
  • kelvin0 9y ago
    Ask not what your framework can do for you, but rather what YOU can do for your framework.
• Touche 9y ago
  I think this premise is wrong: > 2. As a corollary, your app's codebase should be universal — write once for server and client This is a mistake a lot of developers make. The server and client are not the same. As far as rendering HTML goes, the client does a superset of what the server does. This means either the framework has to be without leaks; meaning you never need raw DOM access at all, OR it means once you do need lower-level access (for doing animations, for example) you are in trouble. You now have a problem where you have some code that needs to only run in the client. So you have to special case that code to check if running on the server. And you need a strategy for what to do in the server (do you just omit this part, or do you try to do something more basic or what?) In my experience you run into more pain trying to plug the leaks in these "universal" apps than you would if you just had separate server and client templates. Remember that the rule of 3 is the rule of 3, not the rule of 2. https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
  • rich_harris 9y ago
    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!
    • Touche 9y ago
      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.
      • rich_harris 9y ago
        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!
• deleted 9y ago
  [deleted]
• auggierose 9y ago
  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&cd=1&cad=rja&uact=8&ved=0ahUKEwiA6PvX2bnYAhULb1AKHaABCYgQFggoMAA&url=http%3A%2F%2Fspiral.ece.cmu.edu%3A8080%2Fpub-spiral%2Fpubfile%2Fpaper_284.pdf&usg=AOvVaw3yPlVCT73I81zdV7vNmkVJ https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web...
  • zimablue 9y ago
    "compiler as framework" This really does sound like we're slowly reinventing lisp
• chaostheory 9y ago
  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?
  • rich_harris 9y ago
    It's just an Express app, so you can use whatever datastore you like — create a `routes/api/some-endpoint/[thing].js` file and export a request handler that interacts with your database of choice (or local files, or whatever). 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.
  • dbbk 9y ago
    > Is there a reason why most Javascript web frameworks, like this one, tend to ignore relational databases? Yes, because these are frontend frameworks and that is a backend concern.
    • chaostheory 9y ago
      I could be wrong, but this doesn't look like a front end framework.
• QGmLe 9y ago
  An ideal web app framework would not be in JavaScript...
  • meathook 9y ago
    It's fine to hold that opinion, but in order to usefully contribute to this conversation you need to give a concrete reason why.
    • mwcampbell 9y ago
      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 ahead of time to efficient JVM bytecode, as well as efficient JavaScript and, for good measure, efficient native code for iOS and Windows. 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.
      • ricardobeat 9y ago
        Have you looked at HaXe?
  • wcarron 9y ago
    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.
• deleted 9y ago
  [deleted]
• DougWebb 9y ago
  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/ 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 breakthrough design decision. Finding the code responsible for a given page is easy, because you can just look at the filesystem rather than playing 'guess the component name'. Project structure bikeshedding is a thing of the past. And the combination of SSR (server-side rendering) and code-splitting — something the React Router team gave up on, declaring 'Godspeed those who attempt the server-rendered, code-split apps' — is trivial.
  • rich_harris 9y ago
    If you don't mind reloading the entire page on every single navigation, and don't have any dynamic data or interactivity, this is indeed a very solid approach.
    • RobertRoberts 9y ago
      But this is where the entire argument of "do first page load server side because it's faster" doesn't make any sense. Because then aren't you suggesting that after that, all the other pages can be slow? The worst sites I visit now are React.js like sites, instead of the page load being slow, _everything_ is slow. Ugh. I can't wait until web 3.0 and this silly balogna with the "make a browser with React and run it inside a browser" fades out... (note, Netflix _removed_ their js rendering from their home page cause it was slow)
      • scottmf 9y ago
        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.
        • 9y ago
• antris 9y ago
  Now add to this the ability to write native apps on the iPhone and Android and I'm sold.
• skrebbel 9y ago
  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 because JS is both dynamic and very quirky. Rich, if you're reading this, did you consider this and if so, why not?
  • rich_harris 9y ago
    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.
    • nikcub 9y ago
      > Svelte itself is written in TypeScript I completely missed this as I looked at the sample project and saw js files - this has me going back and taking a second look, so you might want to mention it.
    • stephen 9y ago
      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.
      • rich_harris 9y ago
        Learning a new framework is intimidating enough without potentially having to learn a new language on top of it. I work in the news business, among people who in many cases learned the bare minimum of JavaScript necessary to visualise data and tell interactive stories, so that's my natural constituency — beginner-to-intermediate/casual programmers, most of whom don't even know what TypeScript is. There are TS-first frameworks, such as Angular, and they're off-putting to people who just want to build something.
• bryanlarsen 9y ago
  "While it's true that citing 'ecosystem' as the main reason to choose a tool is a sign that you're stuck on a local maximum, apt to be marooned by the rising waters of progress, it's still a major point in favour of incumbents." Yet the article makes clear that React is working on implementing some similar technologies. Is there anything in svelte / sapper that cannot eventually be implemented in React / next.js too? I'm more than willing to wait a year for it to show up in React rather than live on the bleeding edge...
  • rich_harris 9y ago
    So far, the React team's work is focused on optimising your app code using Prepack (kind of like Angular's AoT compilation, or similar forms of preparsing that have existed in other frameworks for a few years) — you still need React itself. It's far from clear that it'll ever be possible to compile a React app to something that doesn't need virtual DOM reconciliation, with all that entails.
• breatheoften 9y ago
  “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.”
  • ricardobeat 9y ago
    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)?
• kiernanmcgowan 9y ago
  Question: > 1. It should do server-side rendering, for fast initial loads and no caveats around SEO Is server-side rendering still an issue for SEO? Don't major search engines evaluate pages now so that SPAs can be indexed?
  • LeonM 9y ago
    I can confirm that Google can crawl SPA's like any other page. But do note that they crawl using Chrome 41 (!) so make sure you have sufficient polyfills in place. This also applies for AdWords, it drove me mad when Google kept insisting my site was not reachable, even though it was. Only after installing a client-side exception tracking tool (like raygun or errorception) I found out the page was not rendering on the 'old' browser Goolge uses internally.
  • ravenstine 9y ago
    It's not as much of an issue for SEO, depending on what you're using to render. The bigger problem is Facebook, Twitter, and the like are not going to run JavaScript to read your meta tags. It's not an issue for everyone, but if you're a publisher of articles then you're still going to have to render something from the server. Of course one can come halfway by only rendering the head tag contents and not producing a body, which is where most of the complication comes from.
• ashelmire 9y ago
  "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 https://www.youtube.com/watch?v=Wm2h0cbvsw8
  • jazoom 9y ago
    Because then we'd all still be using an improved Angular, or even something earlier. If that's what you want then you're welcome to make that happen for yourself.
• dfabulich 9y ago
  I think the major missing principle on this list is "streaming." (This is missing in Next, too.) The server should send down parts of the page as soon as their data becomes available. Typically, pages have a "header" section that requires no data at all, and the server should render it instantly and stream it to the client. Then there's typically some fast-loading "above-the-fold" data; the server should render and stream that as soon as it's ready. Beyond that, there's other below-the-fold components, which may load/render more slowly. The server should render those as they come in. Then, the magic technique is to progressively attach event listeners to components as they stream in, so you don't have to wait for the whole page to load to be able to interact with above-the-fold components.
  • rich_harris 9y ago
    Sapper supports partial streaming if you have data that needs to be loaded asynchronously (i.e. you'll get most of the <head> immediately, then other stuff later), but it doesn't currently do what you suggest (such as loading a <header> while <main> is pending). That's something that we intend to tackle in future, though hydrating pages with async data dependencies is a hard problem.
• deno 9y ago
  Some bullet points are missing from the “perfect framework” list: 1. SSR must support streaming 2. SSR must work in a service worker (so in fact you have 3 targets: server, client/hydration, client/service worker) 3. All work that can be offloaded to a WebWorker must be offloaded 4. Navigating to subsequent pages must support prefetching, including dynamic data (Next.js doesn’t even tell you how to do it) 5. Navigating to subsequent pages SHOULD support prerendering (offscreen) where it makes sense, but… 6. MUST support FLIP-style transitions[1]. Which does mean prerendering anyway for about 100ms at least so the layout can stabilize and cached images load into memory. For long pages you need to split them into chunks/sections and only animate the part that gets shown (usually above fold). [1] http://www.pocketjavascript.com/blog/2015/11/23/introducing-pokedex-org http://www.pocketjavascript.com/blog/2015/11/23/introducing-...
  • rich_harris 9y ago
    This is an excellent list, thank you. To answer some of the points: Sapper supports partial streaming of server-rendered HTML (typically you'll get most of the <head> while it's fetching data for your page, unless there's no dynamic data in which case you get the whole lot instantly). I'm not convinced there's actually a benefit to 'server' rendering in a service worker as opposed to serving a shell page. We have an issue for it though! (https://github.com/sveltejs/sapper/issues/22 https://github.com/sveltejs/sapper/issues/22) Sapper supports prefetching (including of dynamic data) of subsequent pages — just add rel=prefetch to <a> elements (we'll add a programmatic way to do this in future as well). As for the rest, some of it is app-specific, some of it is stuff the framework could help with. We're not at version 1 yet, so bear with us :)
    • deno 9y ago
      It should be “free” with the right architecture, and it should be faster, that’s why I included it for the “perfect” framework list. However, it’s only a win on first page load on a subsequent visit. So definitely not a priority for an actual implementation. BTW one easy way to implement this would be to flip the usual model: 1) Have service worker/server as main renderers 2) On navigation do a fetch to service worker and patch the page So you’re on /main, do fetch to /page2?from=state and get patching instructions. If you could give the service worker readonly access to DOM without copying this wouldn’t actually be that stupid. It might be possible some day: https://github.com/whatwg/dom/issues/270 https://github.com/whatwg/dom/issues/270
• dmitriid 9y ago
  What I don't get in all these frameworks is the desire to invent new and incompatible template languages with increasingly inane syntaxes. Oh. And, of course, with stringly-typed programming and magic binding rules. Just look at Svelte's templates: https://svelte.technology/guide#template-syntax https://svelte.technology/guide#template-syntax Not only it's some custom implementation, it also breaks all assumptions about javascript code const counter = new Counter({ data: { count: 99 } }); ...then {{count}}, or counter.get('count') Why is it `counter.get('count')`? WTF? Or just the section on computed properties[1]: oh, it's no longer even Javascript. It's some magic Javascript-like scripting language that gets injected with properties based on what you write. Much like in Vue data, properties, and methods are magically hoisted up to the object breaking everything you learned about Javascript: export default { methods: { say: function ( message ) { alert( message ); // again, please don't do this } } }; // and then import MyComponent from './MyComponent.html'; var component = new MyComponent({ target: document.querySelector( 'main' ) }); component.say( '' ); Why the hell is `.say` a top-level method now? And so on and so forth. [1] https://svelte.technology/guide#computed-properties https://svelte.technology/guide#computed-properties
  • purple-again 9y ago
    I’m not an expert can I can chime in and say that .get and .set are common in Ember data objects as well. No idea if it’s an ES6 thing or Ember thing though.
    • dbbk 9y ago
      Those are Ember-specific, because ES getters and setters weren't widely available at the time of introduction. They just dropped < IE 11 though so they'll start to go away.
• tobr 9y ago
  Curious: why use Webpack rather than your own and IMHO much superior bundler, Rollup? I’m excited to try this more but I have mixed feelings about Svelte. The concept is brilliant but I feel like there’s too much API and some weird gotchas. I hope there’ll be an effort to simplify it if possible.
  • rich_harris 9y ago
    It uses code-splitting, dynamic imports and hot module reloading, which are all well supported in webpack. We definitely plan to support Rollup as well, once it has those features — it should be possible to shrink down JS payloads by a reasonable amount. (Maybe Parcel too, eventually.) I think the 'too much API' feelings might be more unfamiliarity than anything. The API surface area is much smaller than anything like Angular, Vue etc, and although it's a fundamentally different approach to React I'd argue Svelte has a much shallower learning curve there as well. We're very open to feedback and suggestions though!
    • tobr 9y ago
      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 there both {{#if condition}}<p>Content</p>{{/if}} and {{{condition && '<p>Content</p>'}}}? I feel like all these different concepts break the "it's just HTML" promise, when it seems like it could be simplified a lot. Yes, JSX has similar gotchas, but at least it has references and specifications. And what's up with the crazy semantics of computed properties? Sorry if this sounds negative, but these have been genuine problems for me in getting a hang of Svelte.
      • rich_harris 9y ago
        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}}...{{/if}} tells Svelte something about the structure of your app. {{{condition && '<p>Content</p>'}}} doesn't, and you can't add interactivity to the <p> if it's just a string. Moreover, if `condition` is `undefined`, then that's the string that will get rendered to the DOM. Generally, {{{triples}}} should be used for blobs of HTML you get from data sources, such as a blog post. If you can overcome your distaste for the computed property dependency injection, you'll hopefully find it's an extremely easy and compact syntax for declaring arbitrarily complex graphs of properties. The advantage of doing it this way is that Svelte can generate, at compile time, very efficient code for updating computed properties without any wasteful runtime dependency tracking. I realise it's slightly controversial (because it's a Svelte idiom, rather than something in JS itself), but for those who have embraced them, computed properties are one of the best features of Svelte!
• AiDirex 9y ago
  How the fuck something that is in early development advertises as military grade!
  • aspiringuzer 9y ago
    Getting new technologies to gain traction is not easy - regardless of their technical merit. I do admire the framework designer's P.T. Barnum like showmanship. He's got it down to a science.
• young_greedo 9y ago
  ITT: a complete misunderstanding of how a universal JS web app works.
  • thomasfromcdnjs 9y ago
    Agreed. As a JS app developer I now feel more confident about my job security.
• aspiringuzer 9y ago
  I've used many web frameworks over the years and I really wanted to like this Sapper technology, but for the life of me I just don't understand what problem it's trying to solve. Can someone give me a comparison of what comparable technologies it is replacing?
  • innocentoldguy 9y ago
    There hasn't been a new, shiny JavaScript framework out in a few days. Perhaps Sapper is trying to solve that?
  • arxpoetica 9y ago
    There isn't really anything comparable. Really. It doesn't include the framework in the end build. It's only in the original source. So it's a compiler, not really a framework, that compiles to code that's performant to specific tasks.
• pwaai 9y ago
  How many of you actually built a React/Redux stack SPA that actually came anywhere near what Sapper offers? The file size problem is underrated. Not everybody walks around with 5G like in South Korea. Not everybody has the latest and greatest Samsung or Apple phone. It's a big problem when you advertise PWA as quick and fast but then in tiny letters mention its using the best case on best network and best phone. If you design without worst case in mind, you've discriminated people based on whether they can afford the best or not. The vast majority of users don't. It's only recently that Android phones have gotten cheap that its seeing widespread usage. These people are not going to wait around for the React/Redux stack to load AND still wait on more data coming through their 2g/3g connection. Oh, and there's slow rendering on older Android phones and now you have a laggy Javascript app experience that Lighthouse tells you everything is okay. Let's not be so quick to judge. It's not as if Sapper has deviated from the trend that even React team is acknowledging. This is a fresh approach to a quickly monopolizing space, from an organization that has other agendas in seeing their tech stack flourish. I'm gonna definitely be watching Sapper.js in 2018 and if they deliver on most of the 11 criterias, I know my customers and their customers will be happy.
  • mlsarecmg 9y ago
    You can boil down react to virtually nothing. preact-compat turns it into 4kb. Redux + router don't add that much. The loading impact, if you watch out, code split, isn't the dire problem. As for laggy experience, Fiber is the only feasible attempt at the moment to actually tackle it. Microbenchmarks will not help and neither Svelte nor anything else will make a webapp fast on a slow phone as baseline diffing has never been the problem in the first place. The problem is and has been the dom and the single threaded handling of it. Fiber will allow apps to schedule. Imagine an app with 100.015 rows that Svelte renders in, say, 500ms, let it be 10ms faster than React 15's 510ms. It would still eat into your frame budget and cause heavy jank like all web apps do. Fiber just wouldn't render the 100.000 rows that don't fit your phones screen finishing the whole op under a single ms. It culls and prioritizes similar to how virtual lists operate in general, but you get that as a first class primitive being able to defer any render call of lesser importance without causing visual distortion or code complexity. Not to mention that with React you could actually produce a real native app, while redux would allow you to share most of your code. With something like react-native-web you could even write a universal app being able to render both in the web and natively.
• nwmcsween 9y ago
  Could webpack be replaced with something else? IMO webpack is a giant mess.
  • arxpoetica 9y ago
    Have you had a look at Rollup.js (incidentally by the author of Sapper).
• Rauchg 9y ago
  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 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 now, Next.js instead gives you full flexibility on how you want to match the routes on your server (as it should be). For example, `your-domain.com/xyz` can even first perform a database query before deciding what page to render it with (if any). 2. What the author points out as a weakness here is that you can handle server things directly in your server code (`server.js` using micro or express for example). That sounds like the right thing to do to me, and if you don't want that, you still can do something like: // pages/my-server-page-only.js export default ({ req, res }) => res.end('hi') 3. "To use the client-side router, links can't be standard <a> tags." This is by design. Magically overloading `<a>` to add client-specific behavior sounds like the days of jQuery or TurboLinks. If you want client-side behavior, wrap `<a>` in the higher-order `<Link>` component. There also very important properties of the `<Link>` like `<Link prefetch>` that are simply not part of the `<a>` standard definition. Also noteworthy: the entire ZEIT Documentation is written in Markdown with React components. It's open source: https://github.com/zeit/docs https://github.com/zeit/docs 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. Our team actually spends more time on the 'compiler' parts of Next.js than the 'framework API' parts. (the API has barely changed since the initial 0.1 release in fact). Additionally, since Next.js uses React as peer dependencies, you'll also get to do `yarn add next react react-dom-lite` https://github.com/jquense/react-dom-lite https://github.com/jquense/react-dom-lite in the future. Overall, I think Sapper is an excellent framework for Svelte users. I'm looking forward to seeing more Next.js-like frameworks. For Vue users: check out https://nuxtjs.org/ https://nuxtjs.org/!
  • rich_harris 9y ago
    Thanks Guillermo. I hope the respect and appreciation I have for the Next team came across in the post. 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 <Link>, which is that your content is likely to come from a database. (Incidentally, Sapper does provide support for <a rel=prefetch>, which works exactly the same as <Link prefetch>.) > 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.
• christophilus 9y ago
  Sounds interesting. He mentions that his gzipped size for the RealWorld project is about 40KB. There was a good comparison done with this project[0] in which one of the frameworks (AppRun) weighed in at 19KB. 19KB is pretty crazy. Has anyone here used AppRun? [0] https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-e1cb62fd526c https://medium.freecodecamp.org/a-real-world-comparison-of-f...
• antihero 9y ago
  Why on earth would I give a shit about SEO for a web application? The SEO is for the brochure site that leads people toward the webapp, not the webapp itself...
• _greim_ 9y ago
  > the framework should do automatic code-splitting at the route level, and support dynamic import(...) for more granular manual control I disagree! Code-splitting is arguably an architectural dead-end for SPAs: 1) It adds a non-trivial layer of complexity to both your application logic and your tooling. SPAs (and the JS ecosystem in general) are already complicated enough without this extra layer of indirection, and that complexity carries a higher cost than most people realize, especially when it's blindly accepted across the industry as best practice. 2) It's based on the conflation of apps with collections of hypertext documents, whereas in reality these are different architectures with different trade-offs. We're under no such delusions for apps in the app store for example, and thus nobody bats an eye if one takes a full minute to download. I guess this isn't what people want to hear, but the web is more than apps, and we need to stop pushing SPA as the default way to build every new website. Code-splitting is merely the by-product of choosing the wrong architecture. In cases where SPA is the right tool for the job, we need to make users aware that they're downloading an actual app. I.e. a one-time install screen implemented via some kind of service-worker-driven bootstrapper: "Just a moment while we install your app..."
  • lfischer 9y ago
    It’s an interesting idea. From the case studies you’ll find on the web, it looks like Progressive Web Apps want to play minimal bootstrap time as as card against native apps, but it’s true that re-use of existing web know-how could be enough arguments in their, although native app developers are getting almost as easy to find as web developers these days.
• cryptica 9y ago
  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 before launching yet another project that's going to waste several more lifetimes of human effort. There was nothing wrong with the implementation of the MeteorJS project by the way... The problem was the idea itself. All the marketing and funding it received only served to delay its inevitable demise.
  • lfischer 9y ago
    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 MongoDB) was the greatest limitation.
    • arxpoetica 9y ago
      THIS.
• Ros2 9y ago
  Hey Rich, your hackernews clone doesn't perform all that well globally https://testmysite.io/5a4c2cdf819876444fa127b5/hn.svelte.technology https://testmysite.io/5a4c2cdf819876444fa127b5/hn.svelte.tec... I really like Svelte! But I don't even serve my content from Express middleware anymore due to the above problem. I just feel like you're under-estimating a developer's resourcefulness to make the content that actually is static a static page, and also over-estimating the number of new, traditional client/server web apps (at least by people who are probably in your target audience). Static performance is hard to beat especially globally and there's a clear performance degradation once you get away from the epicenter. Believe it or not Svelte.technology's landing page actually performs noticeably more poorly coast to coast in the US (>2x worse to load in California than NY--150ms vs 500ms). I'm not saying give up or anything, just saying it might be a good idea to talk to more JAMStack people :)
  • rich_harris 9y ago
    This is more of an ops thing than a framework thing. If you're making a purely static app, JAMStack is great. Sapper is solving a different problem. Having said that, we will eventually add the ability to 'export' a purely static site that can be deployed to services like Netlify. Next.js has this, but they didn't launch with it either. Bear with us!
• jchook 9y ago
  If you can "customise every aspect of the system" why does he spend a whole paragraph complaining about people who like JSX? Shouldn't the answer be, "and you can use JSX if you want"?
• jitlerr 9y ago
  Is there any way to use Sapper.js with React, Vue or anything framework? I find the premise behind Sapper interesting, but I just don't see the appeal of Svelte, where they are basically reinventing HTML syntax.
  • rich_harris 9y ago
    Svelte is the premise behind Sapper. If you want to use React, use Next; if you want to use Vue, use Nuxt; if you want that 7kb Hello World (instead of Next's 204kb or Nuxt's 175kb) then you have to adopt a more efficient approach. We're not reinventing HTML, we're using HTML. And CSS. ('Reinventing HTML' is a far more fitting description of JSX, and then there's CSS-in-JS...) Doing so is what allows us to statically analyse your app and compile it to a) a tiny client-side JS payload, and b) an incredibly efficient server-side renderer.
• techaddict009 9y ago
  Why dont you guys use laravel when you need better SEO and server side rendering? It is fast, easy to learn, easy to deploy, etc.