yep, looks like I broke something with a recent commit. D'oh. Not in a position to fix right now... moral of the story, no website is too trivial to have acceptance tests
Fixed now thanks to njb in our Discord chatroom! God I love open source (and Travis CI) - was able to deploy this fix from my mobile phone while watching the brazil-belgium game
I had a look at Svelte in the early days but went with something more mature for the project at the time. I actually recently landed on Sapper while looking around tab Web Component projects and it looks good, though I haven’t had a chance to try it out yet.
edit: also, read a lot of comments about "why the military tagline". It's a play on the name Sapper. An old buddy of mine is one up in the CAF in Edmonton. They're combat engineers— hence the military tag.
I associate the military with wasteful resource management and glacial innovation speed. The military in my country courently does not have working helicopters (they ran out of spare parts) and the rifles they use overheat and bend in combat..
Would love to try this. Is there some kind of open-source kitchen sink application that outlines best practices for concepts like:
- Internationalization
- Handling auth w/ SSR
- Server side pre-rendering (in case I want to pre-render a template and conditionally cache/expire the HTML for N hours, for better perf instead of rendering on each request)
We haven't yet developed a full set of best practices around i18n, but the SSR/SEO stuff comes for free with the Sapper model. See https://github.com/sveltejs/realworld for an auth example - better and more self-explanatory ones to come (project is still in early stages)
Yeah, my first reaction to that was to stay away, I wouldn't want to use something created by a team that thinks "military grade" JavaScript is something to brag about.
I will say that a front-end focused framework that even acknowledges the existence of a backend is refreshing. And this seems to be a framework in the classic sense - a complete solution to deliver a particular type of app, rather than a library that handles one aspect for you.
That's not everyone's cup of tea, but it is an area that doesn't have a lot of attention in modern JS libraries.
The same question would have been valid during the creation of React, or Webpack. People create new frameworks and tools to try to solve pain points, sometimes they're runaway successes like React or Angular 1, sometimes they're good complimentary tools like Vue.js, and sometimes they fall completely flat, like perhaps Batman.js. Either way, the question of whether we need a new JS framework is not very productive. The right question would be, what can a new JS framework offer that would be worth switching to it for? The answer will differ per team and application.
The more frameworks, the more there are to learn. The more effort required to learn all frameworks, the more appealing it becomes to roll your own.
(The combination of choice paralysis and opportunity cost analysis are a powerful motivator, especially when one comes to the budding realization that even the mightiest frameworks are full of irks. More fun in being a total NIH control freak.)
In my opinion; It's important that people try to innovate diverge and make things different. Like the theory of evolution in nature, ideas change and merge, some die out some live on.
But, each new iteration of an framework, library or distro will provide some new insight of what can be done better ... or what should not be done.
Hey all - Sapper creator here. Wasn't expecting to see this on HN, and not in a position to fully join the discussion (ie I'm in a pub) but happy to answer any questions when I can. This is an early project that is still in very active development (we have some very exciting stuff planned), but for a quick primer here's a blog post that sets out our stall a bit: https://svelte.technology/blog/sapper-towards-the-ideal-web-...
Is it possible to support functionality where I can have my components and pages written in javascript but be rendered as server-side only?
I like client-side rendering for certain things; however, I don't really want it for every component/view within a javascript framework.
What I want is the flexibility to write declarative components with localized state but only introduce client side rendering when I want to introduce it.
I feel like the universal approach can be a bit heavy handed in that everything is getting rendered both on the server and the client. I would love to have something like Angular 1.* but with more structure and server side rendering.
I used it a few years ago and one of my favorite aspects was using primarily for generating templates server side, and only upgrading to a client component when things became more complex. Out-of-order async rendering was pretty nifty too.
One of the advantages of the Svelte approach is that you can theoretically make those determinations at compile time - if there's no interactivity on a page, don't serve any JavaScript. We're not quite there yet but it's very much on our radar. You should be able to use a consistent programming model whether you're building an app that makes most sense as a purely server-rendered app, an SPA, or something in between - especially since your requirements can change unexpectedly - and if the framework is designed correctly, it shouldn't even require configuration.
I was definitely looking at Svelte, Vue, and React for this.
I played around with Nuxt and couldn't get it to work in a way where I could avoid rendering on the client. It's not a bad framework, but it doesn't work for the purposes that I am looking for.
What I am doing today is using Ruby and Sinatra for the back end. I have figured out a way to build out a light weight component system where this is an html view, some vanilla js for interactivity, and CSS for styling.
The problem is that it is really difficult to localize the scope of the js and I have to work with the DOM to add interactivity. Scoping the CSS isn't necessary but would be nice.
I don't dislike doing things in Ruby, but I am very much attracted to the idea that I can use one language for the server and client logic and avoid having to tap into the DOM for managing state.
hey rich! i saw your JSConf demo, its a real shame about all the technical difficulties - do you mind do a youtube recording of those parts of the talk again so we can just see what you were trying to demo? really super promising though, and i love your entertaining style. you have a really special combination of talents, thank you for being you.
Any plans to officially support TypeScript in Svelte and Sapper? It looks like the Svelte compiler and all of Sapper are written in TypeScript, but the Svelte runtime bits aren't. Also, considering that Svelte essentially has its own DSL based on HTML, with inline JavaScript, I guess existing IDE support for TypeScript wouldn't be sufficient. I'd happily take the type checking and extra language features without the IDE support, but I guess I'm in the minority.
Maybe off-topic but the website is noticeably faster than the Svelte guide (https://svelte.technology/). Is it built on Sapper itself? Or is it just a static site?
Both sites are written in Sapper. The difference is that the Sapper site can take advantage of Sapper's `export` feature, which generates a static site from your codebase, Gatsby-style (except with much less JS). That's probably why it's faster for you (though there'd be less of a difference if I was better at devops)
First reaction, very nice, I spent about a year on vuejs but I missed the structure of django. This looks promising, only had a quick look, will write something small to get a feel for it. Heard of Svelt quite recently through recommendation
Sapper user here. I've been building a project with it, using it for about 6 mos. and really putting it through its paces. For a project still in active development and undergoing a lot of changes pre-version 1, I've been extremely pleased with just how little I've had to think about stability and other back-to-front-end concerns.
For the “yet another new js framework” people out there, in some ways, it's true that Sapper isn't necessarily bringing anything new to the landscape (though I have been very pleased with some of the best-practices adopted-- so much is so-well thought out, and Rich Harris is just a freakin' genius at web systems engineering).
BUT
The combination of ingenuity with what Svelte does is completely novel, and in that sense, Sapper is really a different beast-- not just another framework. In that regard, one can't really talk fully about Sapper without also talking in depth about the novelty of Svelte, the "disappearing framework."
The "what" and "how" of Svelte (and Sapper) have been nicely covered elsewhere (article above, for example), so I won't really touch too much on it. But, as a non-n00b in the Internet landscape, I'll just throw out this hyperbole: there really hasn't ever been anything like Svelte and it's pre-compilation process before in front (and back) end technologies, and it's really just a full on joy to work with it.
If you want to get a quick taste, just go check what we Svelters like to say is one of the best kept secrets on the Internet, the Svelte REPL: https://svelte.technology/repl
50 comments
[ 4208 ms ] story [ 4125 ms ] threadI had a look at Svelte in the early days but went with something more mature for the project at the time. I actually recently landed on Sapper while looking around tab Web Component projects and it looks good, though I haven’t had a chance to try it out yet.
edit: also, read a lot of comments about "why the military tagline". It's a play on the name Sapper. An old buddy of mine is one up in the CAF in Edmonton. They're combat engineers— hence the military tag.
https://news.ycombinator.com/item?id=17472194
https://en.wikipedia.org/wiki/Sapper
New fancy TLD, the most generic name you can think off... so this is probably gonna get bought pretty fast!
- Internationalization
- Handling auth w/ SSR
- Server side pre-rendering (in case I want to pre-render a template and conditionally cache/expire the HTML for N hours, for better perf instead of rendering on each request)
- SEO / Helmet type stuff
That's not everyone's cup of tea, but it is an area that doesn't have a lot of attention in modern JS libraries.
PSA: Don't make a new JS framework guys we don't need any more. /s
(The combination of choice paralysis and opportunity cost analysis are a powerful motivator, especially when one comes to the budding realization that even the mightiest frameworks are full of irks. More fun in being a total NIH control freak.)
But, each new iteration of an framework, library or distro will provide some new insight of what can be done better ... or what should not be done.
I like client-side rendering for certain things; however, I don't really want it for every component/view within a javascript framework.
What I want is the flexibility to write declarative components with localized state but only introduce client side rendering when I want to introduce it.
I feel like the universal approach can be a bit heavy handed in that everything is getting rendered both on the server and the client. I would love to have something like Angular 1.* but with more structure and server side rendering.
I used it a few years ago and one of my favorite aspects was using primarily for generating templates server side, and only upgrading to a client component when things became more complex. Out-of-order async rendering was pretty nifty too.
I played around with Nuxt and couldn't get it to work in a way where I could avoid rendering on the client. It's not a bad framework, but it doesn't work for the purposes that I am looking for.
What I am doing today is using Ruby and Sinatra for the back end. I have figured out a way to build out a light weight component system where this is an html view, some vanilla js for interactivity, and CSS for styling.
The problem is that it is really difficult to localize the scope of the js and I have to work with the DOM to add interactivity. Scoping the CSS isn't necessary but would be nice.
I don't dislike doing things in Ruby, but I am very much attracted to the idea that I can use one language for the server and client logic and avoid having to tap into the DOM for managing state.
For the “yet another new js framework” people out there, in some ways, it's true that Sapper isn't necessarily bringing anything new to the landscape (though I have been very pleased with some of the best-practices adopted-- so much is so-well thought out, and Rich Harris is just a freakin' genius at web systems engineering).
BUT
The combination of ingenuity with what Svelte does is completely novel, and in that sense, Sapper is really a different beast-- not just another framework. In that regard, one can't really talk fully about Sapper without also talking in depth about the novelty of Svelte, the "disappearing framework."
The "what" and "how" of Svelte (and Sapper) have been nicely covered elsewhere (article above, for example), so I won't really touch too much on it. But, as a non-n00b in the Internet landscape, I'll just throw out this hyperbole: there really hasn't ever been anything like Svelte and it's pre-compilation process before in front (and back) end technologies, and it's really just a full on joy to work with it.
If you want to get a quick taste, just go check what we Svelters like to say is one of the best kept secrets on the Internet, the Svelte REPL: https://svelte.technology/repl
> site is blank without javascript
:-/