overtowed

> it is literally their job to capture the entire thing and whatever else they can capture

Their job is to maximize shareholder value, and if attempting to capture the entire thing reduces shareholder value, which may occur in this case, they're not doing their job well.

Hey author here. This is a map of Earth that uses NASA imagery[1] to roughly sketch how sea levels could change if all ice melts. Estimates of potential sea level rise vary, with most I've seen between 60 and 75 meters. (some are higher) This map shows about a 65 meter rise. The resolution is poor and just pixels, making it more of an aesthetic experience than a scientifically useful one. (there are many good tools for that)

The map[2] is not mobile friendly and requires WebGL. I recorded a video that tours through the map to music.[3] It's the same experience as pressing "begin tour" on the map. The website version will have better visuals because of video compression.

The map is rendered with WebGL via PixiJS and the rest of the app is Svelte. The original DOM implementation was written in Svelte but it was too inefficient, the bottleneck being the DOM and not Svelte. You can test the difference yourself on the map by pressing `ctrl+backtick` to enter dev mode and clicking "webgl" to toggle over to the DOM version. On my machine, the Pixi version drops no frames in all browsers, and for the DOM version, Firefox drops about 1 in 10 frames and Chrome/Edge are sludge, seemingly because they're shy about using more GPU. The source code readme[4] has some technical notes discussing Svelte and Pixi[5], and it links to original DOM implementation with more comments if you're curious.

I'd be glad to answer questions. Not about the science though, I'm a web developer.

[1] https://visibleearth.nasa.gov/collection/1484/blue-marble

[2] https://www.cosmicplayground.org/#deep-breath

[3] https://www.youtube.com/watch?v=7xEPqg-Kyg4

[4] https://github.com/ryanatkn/cosmicplayground

[5] https://github.com/ryanatkn/cosmicplayground#technical-notes

Sure, thank you for the question! It prompted me to add a note about Elm and Dart in a relevant section in the document.

One important difference with Svelte versus Elm is that Elm makes a clean break from web technologies, while Svelte is designed to work with future versions of the web's languages.

Svelte is a component compiler, not a general language compiler. Big distinction! Being purpose-built for this use case opens up a lot of opportunities.

The article goes into this more, but Svelte's DSL is an extension of web languages - not much to learn really! Your existing knowledge of HTML, CSS, and JS transfers directly.

It's not a comprehensive weighing of alternatives, instead it's a deep dive into Svelte's pros and cons as they relate to my experience and our project.

Elm is awesome! There's nothing quite like it that I know of in its design space to bring user-friendly functional programming to the web. Similar to Svelte, its design holistically packages up the web's languages. Compared to PureScript, it's focused on a small and beginner-friendly feature set, trading general power to optimize for the webapp use cases. Elm has also been influential to a lot of toolmakers!

Thanks for sharing!

On point 1, this issue is the one to watch. https://github.com/sveltejs/svelte/issues/4518 Language server support will work for both JavaScript and TypeScript and error/type checking and editor support should be pretty comprehensive when it's ready. Svelte 3 was written with TypeScript in mind, so the idioms are fairly compatible with type checking. (a nice pit of success for design!)

This should also fix reassigning to a const mentioned in point 2.

It's buried in the article, but TypeScript support is being worked on by one of the TypeScript team members in collaboration with the Svelte devs - https://github.com/sveltejs/svelte/issues/4518

The template language's restrictions compared to JavaScript/JSX-built views are part of Svelte's performance story. It's able to optimize things ahead of time that are impossible with dynamic code because of the constraints. Here's a couple tweets from the author about that -

1 - https://twitter.com/Rich_Harris/status/1224414679021301761

2 - https://twitter.com/Rich_Harris/status/948231770725605377

The Svelte template language is quite small, and compositional features like slots and <svelte:component> are powerful. There are currently some unwanted edge-case restrictions as this comment points out - https://news.ycombinator.com/item?id=22541100

I considered linking or footnoting that text and probably should have.

Like all surveys, there's a selection bias. For example where are the world's millions of jQuery developers?

There's also a lot of controversy around Angular's treatment in the survey and an alleged pro-React bias. This shouldn't affect the Svelte numbers much.

Thanks for bringing it up - I'll improve the text somehow.

Svelte can do server-rendered and static page generation with the near-zero overhead of string concatenation, and with it you gain the component model. Part of the magic of compilers is that you can get most of the best of both worlds. Sapper provides both of these use cases.

Good question, thanks for asking it. I didn't explicitly address this (oops) and I'll have to do some more thinking. My first reaction is that:

1) Svelte gives you a solid foundation and lots of flexibility

2) difficulty scaling for large apps is mostly orthogonal to the component library

3) Svelte provides flexible and sugary integration points for these orthogonal concerns

For example, since we're talking large projects, the biggest concern is state management. Svelte is like React here, in that you could use MobX or Redux with a connector library, or RxJS with Redux, or other combinations. As long as your solution is compatible with stores like RxJS is, you benefit from Svelte's auto-subscriptions[1] and sugary store dereferencing[2] that's agnostic to your underlying state management solution.

[1] https://svelte.dev/examples#auto-subscriptions

[2] https://svelte.dev/examples#readable-stores

Author here, just wanted to make a note. This isn't written to hype a battle in the holy war. Frontend frameworks are a positive sum game! Svelte has no monopoly on the compiler paradigm either. Just like I think React is worth learning for the mental model it imparts, where UI is a (pure) function of state, I think the frontend framework-as-compiler paradigm is worth understanding. We're going to see a lot more of it because the tradeoffs are fantastic, to where it'll be a boring talking point before we know it.

author's tweets about its history - https://twitter.com/sebmck/status/1108407803545214977

I'm a JS developer who tried to adopt Reason for a full stack side project in September. There is so much to love about the language and ecosystem. After about a week I decided to start over in TypeScript for a single reason: the awkward interop with promises compared to async/await, which is now available in evergreen browsers and Node 8 without compiling down. I'll definitely try again once this is ready.