Show HN: Sapper.js – towards a better web app framework
svelte.technology
svelte.technology
> 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_progra...
There’s especially no reason for it with modern frameworks like React/Vue/etc - it’s not been a technical problem for years.
I think it does take some time to think universally, but it's not all confusion and hair pulling.
In fact, it kinda reminds me of writing testable code. You need to separate some concerns, but ultimately, it's a set of conventions that help you get there.
I can tell you, there are plenty of times when even a rule of two isn't worth the maintenance effort that's caused by rendering HTML in two different places.
It is an issue, but one that is really easy to handle.
For example, you can't trust client-side code for security/authentication purposes. You almost certainly don't want client code to connect directly to your database and run arbitrary queries/look-ups. So some kind of server-side-only wrapper around your DB, at least, is required.
But the reason you'd run "client" code on the server is to have a layer of universal HTML-rendering code. The server needs to do it for fast initial page loads (and SEO), and the client needs to do it for fast, offline page loads.
At the same time, there's a bunch of code that will run on the client side only, e.g. click handlers, animations, etc. There's essentially nothing for that code to do on the server, but I think it's still basically correct to call it "universal" when you mean "client code that can also run on the server" which is what Sapper provides.
You might be able to write all your app code in Javascript, but the inputs and outputs are so different that you never really avoid "if(isServer()) {...} else {...}". You can't contain that in a single file, either. It surfaces in the most unexpected places and gradually erodes the illusion of "universal," until you're never sure in which order or what environment your code is executed. You'll have pieces of code written and rewritten again and again and executed several times just to make sure it gets called in the exact moment, with the exact arguments you need, at least once.
I spent many years in search of "universal" JS, and worked with many people who were convinced they had found El Dorado, yet always ended up in situations like I described, so maybe I'm jaded.
What we ended up in my case was one chunk of code (server) that extends a shared chunk (server/client), with plenty of server vs. client branching inside the shared chunk, either on a boolean flag or the presence of some data structure that only exists in one environment.
I have never seen the use case that many people flippantly claim is so easy, which is the "one chunk" concept, nor have I seen a chunk of server- or client-only code extend shared server-client code in a way I would describe as clean. Stuff tends to get messy when you have to deal with the space between the server and the client, like cookies, asset loading, or third-party services, or when you have to do fancy UX tricks. Then users who are used to "traditional" websites do things like refresh the page at weird times, click buttons more than once, load the app from the wrong URL, use the wrong browser, click things too fast, leave a tab open too long, and so on. And then, as others have mentioned, you have sensitive logic that needs to live only on the server for business reasons. Then the framework you're using moves too quickly or not quickly enough to support a browser feature you didn't know you needed until right now. All this stuff only comes in later, once the app meets the ground, and is rarely discussed in initial architecture meetings. The only way I could possibly see these solutions as cleaner than the old "two-chunk" way are if I were to automatically dismiss all those pragmatic concerns or consider them to be cleaner simply by virtue of the fact that they're different.
It's frustrating to me because I see so much optimism on online forums about "Universal" JS as this earth-shaking sea change on the verge of happening, even though honestly it's been 10 years since NodeJS came out and first made Universal possible. It makes me feel a bit like an old fogey for throwing up my hands and saying, "Let's just let it go and stick to the original design of the web," meaning, two chunks. But that's the only way possible for me to deliver the real requirements I have on projects without driving myself crazy.
But, to quote from your link:
> and may or may not if there are two copies.
The universalness I want is that I want one language, package manager, toolchain, IDE etc for all the code I’m working on. Worst case would be to have the two platforms being slightly different. Say two IDE’s with slightly different shortcuts, two curly brace languages with slightly different syntax, two different build systems you need to integrate in the CI etc.
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
This is the basic value premise of frameworks. Write less code with uniform conventions and make it easy by hiding the complexity. Unfortunately, the premise is faulty.
You can only lie to yourself for so long that your ignorance of how things really work is fine because of (name your favorite abstraction). This is a very direct example of tech debt. By ignoring how things really work the application will gradually get bigger and slower until it is an incompetent mess like paying off credit cards with other credit cards.
The reason for this snowball effect is largely due to a lack of confidence that feeds upon convenience as opposed to examination of why technical problems exist in the first place.
I find this a great answer.
Much time is spent these days on taping over problems at the high level on the top of broken stacks, instead of fixing the underlying issues.
Building on broken foundations will only get you so far and yield diminishing returns, even if it initially looks easy and convenient to just build on top.
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/. 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.
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)
This comment is a prime example.
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 onto some different wheels.
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.
There is a lot of practical implementation history that people are often woefully ignorant of, and it leads them to tread the same paths over and over and over.
- Here are the core GNU command line utilities; make, sed, grep, etc. They are battle-tested, use them, don't rewrite them a dozen times in JavaScript
- Here is the progression of version control tools that people have used over time, and some reasons why we've moved on from SourceSafe and rcs to Git.
- Here's the history of how people have done databases, flat-file, vs sql vs nosql
- etc, etc, etc.Alan Kay frequently laments the direction of the computer industry, calling computing "not-quite-a-field" and "pop culture". From an interview in 2012:
Quote:
----
> Kay: [...] [I] happen to believe in history. The lack of interest, the disdain for history is what makes computing not-quite-a-field.
> Binstock [interviewer]: You once referred to computing as pop culture.
> Kay: It is. Complete pop culture. I'm not against pop culture. Developed music, for instance, needs a pop culture. [...] The big problem with our culture is that it's being dominated [more by] pop-culture content than it is for high-culture content. I consider jazz to be a developed part of high culture. Anything that's been worked on and developed and you [can] [sic] go to the next couple levels.
[...]
> [Kay continues]: [P]op culture holds a disdain for history. Pop culture is all about identity and feeling like you're participating. It has nothing to do with cooperation, the past or the future — it's living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from]. [sic - brackets in original]
---
It's a great summary of the programming fads that have come to characterize tech culture and how disappointing it is for anyone who is trying to navigate this field with some intent and presence of mind higher than fitting in with the crowd or cashing in on a perceived gold rush.
It's also just a great memorialization of the concept of pop culture in general; pop culture is about a feeling of belonging and community, and engaging positive biological responses associated with social approval and community. It's something that people do to give themselves that rush of praise, and then retroactively try to justify. After a couple of years, no one can understand what anyone was thinking because they were just rationalizing riding the tide.
And, IMO, it aptly describes not only the React phenomenon, but also Kubernetes (aka "shared hosting"), Docker (aka "static linking"), etc. Also IMO, big dollar players stoke this negative culture because it's profitable for them.
It's not necessarily that these technologies won't leave their mark, it's just that they're not the revelations people pretend they are.
Regardless, suspicion is always warranted when people insist that the contemporary is novel, in computing or practically anything else.
[0] http://www.drdobbs.com/architecture-and-design/interview-wit... \ archive: https://archive.fo/DkQOc
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 reloading the entire page. And who cares that this rerender actually takes longer than reload?
This isn’t how it works. Rerenders can be incredibly fast.
>Did I really need to waste 200KB of my mobile data to load scripts all I wanted to see were 5 pages each weigthing 5KB? What did I gain from trading full reload for the a-la-SPA kind of deal?
What did you lose? You lost nothing because SSR provided the initial page load as quickly as any other HTML.
It sounds like you’ve generalized the entirety of modern SPA development from your experience of a few terribly developed sites with poor user experience.
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 ads at us.
PS: It downloads that crappy polymer that weights more than 1.5MB... ffs
Ah, but they do. Browsers are very mature and predictable in their management of html pages and SPA's break that behavior in subtle, uncanny-valley ways.
For instance, click into the Sapper HN page https://hn.svelte.technology/item/16052558, scroll down to a post with a random link and click into it. Click on another page in that link. Now click the back button in your browser to get back to the sapper page. You find that you will be at the top of the page as it re-renders. You lose the place you were scrolled to.
This does not happen with standard cached html pages in the browser.
One of the worst offenders is google's home page. When clicking into the links looking for something, clicking back will take you to top, again and again, losing your place. This is a big step back in usability that people are not even aware is happening. It is a small thing individually, but in aggregate it adds up to a large thing.
What browser is that happening in? In Chrome it works correctly — Sapper uses `history.scrollRestoration = 'manual'` for this exact reason, but maybe it fails elsewhere? It's a bug, and we should fix it. (This is pre-1.0 software, your forbearance is appreciated.)
There are sites that indeed are applications, with lots of updates occurring dynamically on a page: a chat, a dashboard, any type of control interface. They do benefit from the libraries that make highly dynamic things efficient.
There are sites that are best served as static pages. This includes the server component, too, BTW. A static site generator producing plain HTML + CSS is often a good replacement to something like Wordpress.
Some people use latest trending tech for no good reason, just to show off. But the problem here lies not in the tech used.
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?
The reason this stuff gets popular is not because it's a good idea, it's because big companies have tons of cash and man power and can't wait for browsers to get updated. Well, a lot of us code monkey vets are done chasing "shiny crappolla", and we can wait a bit until the dust settles.
How many JS frameworks are there now? I saw all of them come, where is ember, knockout, etc...? Vue just popped up, and I can't even recall the other 5 I tried out at the same time. Which will succeed? When you have to put real money into a project and the framework matters to your clients budget, and your profitability, you can't make a risky bet and expect your client to pay for it later if you are wrong.
I am all for the long term now. Show me how a 1 year old framework is a good investment, I am willing to learn something. (keep in mind React is only about 4.5 years old, Angular is only 15 months old (AngularJS is 7 just years old and already being phased out!))
React will likely be around longer than/as long as any framework, but whatever replaces it will use a lot of the same concepts.
(edit: this is partly a joke comment, fyi)
"No framework" generally means "poorly-written custom framework". Do you have any code samples to share from your vanilla JS apps?
This thinking is part of the problem: the idea that not-using a framework almost necessarily means you're writing garbage.
>Do you have any code samples to share from your vanilla JS apps?
I can show you bad code from popular frameworks too--in particular, hacks to get around the "magic" that frameworks offer.
And, invariably, we move on from the framework because now there's "something better". And, we say "that's just progress". No one wants to admit that the last framework was just bad.
It's a trend that's been going on for decades in programming, and not just with JS frameworks. Stick around long enough and you'll see exactly how predictable it is.
That is not generally true at all. It might be true if you've got a very inexperienced and unskilled team of developers who don't know how to build a non-trivial application without the structure that a framework brings. However, there must be millions of developers in the world who do have sufficient skill and experience to do that, and these days plenty of those people work in web development. I imagine they can still remember how to do things like basic software design and using libraries, which have been working since long before any of these modern frameworks existed.
Even so, the idea that not using a framework automatically means you'll produce some poor imitation instead is laughable. The history of software development is replete with examples of people succeeding without those frameworks. We've built countless UIs that way that were much bigger and more complicated than anyone has ever built with Angular or whatever this week's flavour of JS framework is.
Maybe there are only thousands of developers working in the web industry who could do it rather than millions. I'm not sure that undermines my real point, since you'd only need a handful of decent devs to make and maintain almost any web front-end I've ever seen.
I suspect the true problem is that for various reasons we lose a lot of that experience and skill from the industry far earlier than we should, and then yet another young generation of developers who haven't studied history are doomed to repeat it, badly.
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...
I like the idea of universal code, maybe Sapper will be the solution that comes out winning. I'll let the community be the judges and hop on the train a year later if that's the case.
Moreover, the notion that because FB or whoever went "hmm nothing solves our domain problem, we have the resources to solve it ourselves" that suddenly they solved every domain problem is equally naive. It's likely that people quoting react stacks are solving issues that never existed for them with libraries they don't need.
When was a model like React + Redux (or Elm) used previously, and why did it fail? The combination of factors (browser advances and iteration on existing models) is unlike anything before. This tech stack did not exist in 1999, it did not exist in 2005, and it did not exist in 2012. It is driven by real problems.
What do you mean "a model like React + Redux"?
Programmers have been separating underlying state, rendering and interactions since at least the earliest days of MVC in the '70s.
We've been diffing model states to identify changes to act on for as long as we've had explicit isolated state management, which again is several decades.
We've been identifying specific parts of a display to rerender fully because doing the whole thing was too expensive since the earliest graphical video games.
We've been using markup languages to describe UI layouts declaratively for a long time too.
Adopting similar techniques in browsers was likely as soon as serious front-end coding to build larger client-side web apps became viable, and they have much the same pros and cons now as they did in other UI development before. React and its surrounding ecosystem may have been the first JS libraries to popularise the ideas for a new generation, and IMHO those early versions of React were well done and useful, but let's not pretend the underlying concepts are radical and new in themselves.
But like you said, those are good ideas, they didn't fail.
If it was a good model for building UIs in 1970 and it proved itself then, we should be taking advantage of that on the frontend as well, instead of ignoring it.
That isn't to say some concerns might not have merit, but SEO/SSR/shared routing/state/templates are problems with production-ready OOTB solutions.
If someone isn't familiar with the basic SoTA then they should refrain from commenting so harshly on it.
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, what about browser caching? I can see how the next page loads _only_ the html, as all the js, css and images were loaded already. I think you are falling for the exaggerated speed benefits from making a website with a JS framework.
To be clear, I am talking about a web page, an HTML document, static content. Maybe that's where the confusion happens in discussions like this. (I said "sites", not "webapps" in my original comment)
A history lesson, we did this with Flash years ago (no more page refreshes!), and everyone ultimately learned to hate it. Just because the flashy crap is spread over the entire "webapp/site" to every button, mouseover and click doesn't mean it's useful or better. (I think many devs think they need to build basic site features with big frameworks just to "stay modern".) Look at Youtube, it's slower now that they implemented their "webapp" experience, but the page doesn't "refresh", so that is somehow better... (is youtube really a webapp? Or a bunch of pages with videos on them?)
* 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.
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.
Incidentally, 'cheating' is a bit of a silly word to use for a feature designed to improve UX that people spend a lot of time trying to implement (see e.g. http://instantclick.io/)
How fast would it load if every entry had an image? Maybe then it wouldn't seem so different? (edit: this is from a desktop/Firefox)
Yes, the svelte is generally faster on my phone as well. (I am not sure I see the need for a framework for this specific feature though, it's just a js tabs sort of interface. It doesn't seem like a good argument piece for or against this framework)
I did get a possible error, the pages didn't match up after a while. Is the svelte data was being cached in a way that can't refresh properly? I can't debug this as a normal user, does hitting refresh do anything to reload the site content on the svelte site?
Try this, open both sites in different tabs, and navigate around on them a few times, and after awhile, the news.ycombinator will show new content, and the other one will be different. (I am guessing older content, server cache issue? I didn't compare carefully, maybe they started off different and I didn't notice)
It's 80% more effort for the 20% last performance/richness points.
it's over, people want/expect these kinds of apps, e.g feels as good as native apps but on the web.
But you're also right some people misuse that kind of technology to a ridiculous extent. Downloading a 3MB angular app just to display a crappy site without any rich interactions is really infuriating but that's just bad engineering and people who make choices based on what's popular, disregarding context.
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-100ms. The difference decreases further when you enable server-side compression and start doing fragment rendering, which tends to remove the penalty for HTML payloads.
The argument for react-like technologies is not connection latency, but rather, the hope that you can avoid synchronous connections in the first place by moving your view logic client-side. And truthfully, few client-side apps are written in a way that would minimize payloads anyway. Most people are doing it because they hate working with the DOM and AJAX and server-side frameworks in a mishmash of web technologies, and perceive these client-side frameworks as easier.
I think the question is, who do you write the site for, for others or to satisfy your ego and show off?
HTML is anything but ideal. In fact, it's the core of the problem where Web applications are concerned. HTML and its kin (particularly CSS) were designed for content-oriented Web pages, not Web applications.
Continuing to devise Web-app frameworks that are predicated upon developers wrangling HTML for controls and CSS for layout will lead to more iterations of frustration; only to perhaps slightly lesser degrees. It doesn't matter if you write JS that renders it or templates. It's the same problem.
What's needed is a component-framework with proper tooling (including IDEs) for layout and design. We've solved this with Swing and even Visual Basic. So, for the life of me, I still can't figure out why we haven't moved in this direction full-on for Web frameworks. If the issue is that HTML and CSS are standards with broad support, then I concur: but compose the app via a proper GUI and let the tooling generate the HTML/CSS.
It's odd: we use Webpack, Browserify, etc. for full on Web-app builds, along with various cross-compilers for JS. But, at the end of the day, we're still writing HTML-based templates (or JS) and CSS.
This is generally an unpopular view on HN. But, I can nearly guarantee that the next truly meaningful advancement in frameworks will be via a component-oriented approach that abandons direct manipulation of Web standards like HTML/CSS altogether.
- every time it was attempted, the generated html/css was terrible (think old ASP Net for example), and maintenance hard. Abstractions only work when they are not leaky
- designers, devs and users in general expect to have custom design for everything, rather than standard controls. Something to do with “have a unique brand and not look like everyone’s else app”.
We've come a long way in tooling, libraries, and in the underlying standards. Technologies like ASP also pre-dated SPAs and were targeted for server-side development; hence make for a poor analogy. Swing would be a more apt comparison, and even Visual Basic.
In general, poor execution in the past is no reason to drop the objective. We've tolerated plenty of bad HTML-based frameworks and years of CSS-quirkiness, yet we keep plugging away at it.
>and maintenance hard
But the actual objective is that you wouldn't hand-maintain the generated code. We're currently so bound to HTML-thinking that it's hard to embrace that notion.
>designers, devs and users in general expect to have custom design for everything
I've heard this. Interestingly, though, we look to tools like Bootstrap and design-motifs like Material, etc., which emphasize uniformity. Also, there's no reason branding can't be applied without directly manipulated CSS. A good component-based library would allow for that and would also allow for the construction of extensible custom components.
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-...
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)
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 :)
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:
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!
When look at fiber and react-reconciler, it seems to me react is already contemplating the future. The reconciler especially.
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.
You can skip JSX and write `React.createElement` everywhere, and nothing will change. Your code remains Javascript code. Unlike whatever svelte/sapper is. More details in a different comment: https://news.ycombinator.com/item?id=16053685
Nothing about svelte is "just HTML with styles and scripts". It's a yet another custom weird templating language with its own custom magic binding rules and a Javascript-like scripting language which breaks all assumptions about Javascript (methods/properties hoisting, invalid scoping rules, automatic data/variable injection etc. etc. etc.). And it's also just strings everywhere. And magic strings (as in "add $ to tell svelte the property comes from a store").
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.
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.
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.
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.
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?
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.
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.
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.
There are TS-first frameworks, such as Angular, and they're off-putting to people who just want to build something.
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...
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.
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..."
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.
This really does sound like we're slowly reinventing lisp
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.
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!
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.
{{#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!
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!
Performance-wise, you'll get great results with either framework. You mention debugging — Svelte creates useful sourcemaps, and the generated code is very readable anyway. Svelte has a few features you might find interesting (AFAIK Marko doesn't offer these, though I'm not intimately familiar with it):
* it can compile directly to custom elements * your styles are scoped to the component * declarative transitions * built-in global store (think Redux, but zero boilerplate) * useful element bindings (for e.g. customisable media players https://svelte.technology/repl?example=binding-media-element...) * computed properties. these are a lifesaver when you're doing a lot of complex reactive stuff
and so on. Also, I don't think Marko has an equivalent of Sapper.
Finally, while Marko is slimmer than the likes or React or Vue, there's still a runtime library you need to include on your pages. A typical Sapper page is about the same size as Marko by itself, before you've added any app code.
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()
}
Trouble is, coming from a Vue background (where computed props do not have to rely on a state item), the pre-requisite in Svelte to do so seemed at first a major PITA (then I saw the light/benefits and was actually easily able to re-work the Vue versions to Svelte).
Unless this is the only place Svelte goes slightly 'off-piste' in terms of JS then personally I'd leave as is, otherwise make the change
Just look at Svelte's templates: 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')
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( '' );
And so on and so forth.
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.
> 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?
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.
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.
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 :)
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!
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.
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
[0] https://medium.freecodecamp.org/a-real-world-comparison-of-f...
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')
Also noteworthy: the entire ZEIT Documentation is written in Markdown with React components. It's open source: 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 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/!
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.
nuxt.js applications don't need to rely on filenames for routing. there's a handy nuxt module for this -- https://github.com/nuxt-community/router-module
hmm, I don't even see a mention of how to integrate any datastore with Sapper or did I miss something?
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.
Yes, because these are frontend frameworks and that is a backend concern.
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.
Because I don't know of any. Except maybe the new Rust framework, Yew. Which seems very interesting.
For examples of JavaScript's shitty-ness, I'd point to its various function declaration styles and their disparate effects on the code you write, its wishy-washy scoping, namespacing, the number type's precision problem, NaN being a number type, the ambiguity of this, just to name a few.
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.
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.
i can imagine an app like this. and such an app would have been designed with 0 thought given to the actual usability by humans. the proper solution is to provide sorting, grouping, filtering and pagination. your UIs should be small enough to remain fast without insane optimization tricks. mobile and even desktop browsers are plenty slow at rendering/reflowing 100k DOM nodes; the fastest way to render this is simply not to.
it's not as if suddenly you don't have to worry about the shitty UX and performance of your app's architecture "because fiber".
So it's not really an improvement for me, your component tree becomes harder to reason about (when does this component renders??), you may see very unwanted progressive rendering where you didn't want to, etc. Many vdom implementations are faster than React, synchronous perfs matter a lot too.
Even the core React maintainers acknowledge this is kind of like an experiment.
I don't even know where the scepticism comes from, culling and priotization is normal on the desktop. You've been offloading UI related tasks that could interrupt animations or interactions in C# forever - it is a great tool to have and getting it for the web is a major step. Microbenchmarks that measure baseline deletes/adds/changes will simply not result in apps that feel native. Thinking framework xyz will just feel acceptable to mobile users because Krausest says it takes 1ms less adding 100.000 rows, that is just silly.