Why Svelte is our choice for a large web project - <AUTHOR> https://github.com/feltcoop/why-svelte <comment><AUTHOR> 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.

<comment><USER2> I'm curious that you didn't mention Elm here. Did you look at it and decide not, or not look at it?

<comment><AUTHOR> 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!

<comment><USER2> Thanks, that's useful :)

<comment><AUTHOR> 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.

</comment></comment></comment></comment></comment><comment><USER3> I love React and I love Svelte. There, I said it.

These are the complaints that standout for me with Svelte after using it for a few months:

* Sub-par editor support. For me, the litmus test is whether I can use F2 to rename a variable, and it often does not work inside a Svelte template. There are other places where the editor does not know what to do with your code, because it is not pure JS. Vue is much worse with this since so many things are just strings; React really shines with editor support. This makes a big difference when you are using a large project where you didn't write the code.

* I don't love that you have to re-assign a object/array variable to get Svelte to notice it changed, and you can do that inside a Svelte template to a const variable and you won't get a complaint from the compiler.

* Much smaller ecosystem compared to React and Vue, which is expected at this point.

Other than this, I absolutely love Svelte. Stores are such an amazing abstraction. Animation is well thought out. Storybook works perfectly. Mostly it is pure JS once it gets inside the browser, so you can debug effectively which is not the case with Vue for example.

<comment><USER4> Since you've been using Svelte for a few months after using React, haven't you been hit by the lack of composability in Svelte?

Passing around components as variables is such a common pattern in React, and there's no good replacement in Svelte. The lack of dynamism in components and styles makes theming and crafting reusable components (outside of simple widgets) very tedious [1][2]. I'm genuinely curious how someone can come from React and not be bothered by it.

[1]: [https://github.com/sveltejs/svelte/issues/2106](https://github.com/sveltejs/svelte/issues/2106)

[2]: [https://github.com/sveltejs/svelte/issues/1550](https://github.com/sveltejs/svelte/issues/1550)

<comment><USER5> Passing components is totally supported, and you can use slots. There isn't a single issue I identify with in that GH thread...

<comment><USER4> Slots are currently an unwieldy band-aid.

[https://github.com/sveltejs/svelte/issues/1037](https://github.com/sveltejs/svelte/issues/1037) (open since 2017)

[https://github.com/sveltejs/svelte/issues/2079](https://github.com/sveltejs/svelte/issues/2079)

The simple usage of passing a component to a component, which almost every decently-sized project will make use of, has no convenient syntax, only workarounds:

        // parent.svelte
        <script>
          import Nested from './nested.svelte'
          import Child from './child.svelte';
        </script>
        <Child>
          <div slot="bar">       <-- Extra wrapper DOM node
            <Nested foo="Foo"/>
          </div>
        </Child>

        // child.svelte
        <slot name="bar" {...data}/>

Passing down an element as a prop requires separating the component constructor and its data and manually re-conciliating the two in the child component every time, since components can't be rendered from functions. It works but it's unnecessary boilerplate.

        // parent.svelte
        <script>
          import Nested from './nested.svelte';
          import Child from './child.svelte';
        </script>
        <Child nested={Nested} nestedData={{ foo: "Foo" }}/>

        // child.svelte
        <script>
          let export Component;
          let export componentData;
        </script>
        <Component {...componentData}/>

<comment><USER6> I'm evaluating svelte and have yet to do much, however handling dynamic components is a key requirement, and appears to be supported like so:

      <script>
        import RedThing from './RedThing.svelte';
        import GreenThing from './GreenThing.svelte';
        import BlueThing from './BlueThing.svelte';

        const options = [
          { color: 'red',   component: RedThing   },
          { color: 'green', component: GreenThing },
          { color: 'blue',  component: BlueThing  },
        ];

        let selected = options[0];
      </script>

      <select bind:value={selected}>
        {#each options as option}
          <option value={option}>{option.color}</option>
        {/each}
      </select>

      {#if selected.color === 'red'}
        <RedThing/>
      {:else if selected.color === 'green'}
        <GreenThing/>
      {:else if selected.color === 'blue'}
        <BlueThing/>
      {/if}

<comment><USER4> That's the tutorial challenge code, you get the `svelte:component` solution after clicking "Show me".

[https://svelte.dev/tutorial/svelte- component](https://svelte.dev/tutorial/svelte-component)

But yea that's indeed what I should have done in my example if I wanted the component to be reactive, as you can see that's even more verbose and still doesn't take care of props.

<comment><USER3> I love this thread!

And, isn't it likely this will be easier to support with Svelte eventually? My reasoning is that you just need to add a little syntactic sugar to the language and the compiler can add whatever code is necessary? With a runtime like React and Vue, it seems much harder to add in.

<comment><USER4> It's think it's likely the two issues I highlighted will eventually have syntactic sugar, I never wrote a transpiler but it doesn't seem that hard to support. It doesn't appear to be a priority though.

 _> With a runtime like React and Vue, it seems much harder to add in._

As a rule of thumb, it's almost always easier to add things at runtime than at compile time. That's why it took us so long to get Rust.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> For me, the biggest downside to Svelte is the lack of TypeScript support. This is a massive deal-breaker for myself as well as many other developers. I am also not a fan of the Moustache/Handlebars inspired templating, it feels outdated in the face of enhancing standard HTML or going in the direction of something more extreme like JSX.

I think Svelte is refreshing, but I would not be comfortable using it on a large-scale web application just yet given the downsides, particularly an enterprise LOB application with many moving pieces. This is why frameworks like Angular, Ember and Aurelia on the front-end lend themselves better to the enterprise and React and other more component-based libraries do not.

In terms of community size, I don't think that matters in 2020. You don't need a big community if you have something straightforward and easy to work with. Great read.

<comment><USER8> I submit that any large Ember codebase is intractable without Typescript.

<comment><USER9> I submit that Typescript is largely overrated, adds unnecessary complexity and fails to catch a large number of issues at compile time that it should in fact catch.

<comment><USER7> What are you basing this on?

</comment></comment></comment></comment><comment><USER10> I'm rapidly becoming a huge Svelte fan. Quick self-promotion plug (but in the name of altruism): I've been working on an open source project that glues together Svelte (on the front end) and Crystal (on the back end).

[https://github.com/noahlh/celestite](https://github.com/noahlh/celestite)

Two slightly obscure (but growing) languages/frameworks, but hey, gotta pick a niche. Contributions & feedback welcome!

<comment><USER11> Cool project! Made me actually check out Crystal Lang - looks like a much nicer, modern version of Ruby without the cruft.

Found a straggler "CrystalVue" substring in the main .cr file, you should give 'er the old find-and-replace all to change them.

<comment><USER10> Oh thank you!! I totally missed that.

</comment></comment></comment><comment><USER12> I enjoyed learning Svelte; it was fun to use when I rebuilt a personal project from scratch using it[1].

I'm trying to think of some downsides to balance my enthusiasm for the framework, but can't think of any. The article mentions the smaller community as a possible issue, but the community on Discord seem very welcoming.

Re "using Svelte means adopting a new language" \- it didn't feel like that to me. Every framework has its own way of doing things; Svelte's way didn't annoy me as much as some other frameworks have done in the past (eg: Angular before it became Angular2).

I've got another personal project rebuild coming up - I reckon I'll be treating that as an opportunity to learn more Svelte.

[1] My poetry website (you have been warned!) - [https://rikverse2020.rikweb.org.uk/](https://rikverse2020.rikweb.org.uk/) I blogged about my experiences with Svelte, starting here: [https://blog.rikworks.co.uk/2020/02/01/Recoding-the- RikVerse...](https://blog.rikworks.co.uk/2020/02/01/Recoding-the-RikVerse- website-Introduction/)

<comment><USER13> > Re "using Svelte means adopting a new language" \- it didn't feel like that > to me.

Me neither, but I've been around long enough to remember the handlebars.js days. To someone that's only used React I imagine that at first sight things like {#if} {/if} look ugly as hell. To those people I can only say to stick it out: it starts to feel very natural very quickly.

<comment><USER14> This was my experience. I've been working with Vue for the last few years so Svelte's syntax for loops and conditionals looked a bit funky...but after using it I realised that it's a lot more readable and enjoyable to work with.

</comment></comment></comment><comment><USER15> I LOVE what svelte is doing. I've been using React daily for the last 5 years & it does the job, documentation is world class, community is great, but it still has sharp edges & parts that feel bad. Things like hooks make complicated things look & feel simple, which is great for 80% of my work, but for that other 20% (exit animations, high frequency re-renders, drag-n-drop without HTML5) I do some pretty atrocious things to make it work. This is where svelete shines.

The readme does a good job of pointing out its shortcomings, too. Primarily, no typescript support yet & the unknown bundle size inflection point. As soon as these are solved, I can't imagine it not becoming the best (albeit not most popular) solution.

<comment><USER16> you should look into the libraries of Paul Henschel

</comment></comment><comment><USER17> I applaud the effort and will be following this project closely.

I love the pragmatism of this framework - no solutions looking for problems or complex, badly documented abstractions.

Even if Svelte won't be _the_ next generation framework everyone will be using, the ideas it presents are definitely something the web needs.

</comment><comment><USER18> Having used Svelte for a couple of projects [1][2], I love it. Compared to my day job working in react/redux, it is much simpler, and feels like it has far less boilerplate.

There are certainly a few rough edges, but it's all related to the immaturity of the language. Specifically, I had a hard time understanding transitions and it wasn't at all obvious how to integrate it with D3. Hopefully as it grows we will see improved docs and examples.

Also, I'm holding out for more mainstream TypeScript support. At that point, it would be hard to convince me to use anything else.

[1] [http://musetree.stevenwaterman.uk](http://musetree.stevenwaterman.uk)

[2] [http://optimisation.stevenwaterman.uk](http://optimisation.stevenwaterman.uk) \+ [https://blog.scottlogic.com/2020/02/17/minesweeper- optimisat...](https://blog.scottlogic.com/2020/02/17/minesweeper- optimisation.html)

<comment><USER19> FWIW, our new Redux Toolkit package is specifically designed to eliminate the typical "boilerplate" concerns when using Redux:

[https://redux-toolkit.js.org](https://redux-toolkit.js.org)

<comment><USER18> I do use Redux Toolkit, but it really can't compare to Svelte. There are so many moving parts in a Redux app that there's only so far it can be simplified

</comment></comment></comment><comment><USER20> I watched a tutorial by the author Rich Harris today after reading this link on HN earlier and stopped when he started talking about a DSL he created for Svelte so you don't have to write as much JS. I don't want to learn another DSL. I don't see what the big deal is about compiling. We've have many languages that compile to JavaScript and Google Closure Compiler to tree shake and minify. For years now! Svelte is a nifty DSL to JS compiler that produces small bundles because there is no SDK to back it up or include. Cool, I guess.

<comment><AUTHOR> 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.

</comment></comment><comment><USER21> I dislike the templating pseudo language of Svelte (and many view frameworks). Maybe I am spoiled by react but I never ever want to write my view logic in anything else than JS. This is my main blocker for Svelte.

<comment><USER14> I've never fully understood this viewpoint, which comes up a lot in relation to React and JSX specifically.

The templating in Svelte and Vue is (almost) html with some magic sprinkled here and there, so much closer to the end result. Using JS for everything is moving further away from the metal.

What is it about writing views the React way that appeals to you more?

<comment><USER22> What I found on several consecutive projects was that less the HTML generation resembles the final HTML, the harder it is for people to keep the CSS selectors wired up correctly. Getting text into the page as fast as possible at the cost of layout issues is a sucker's bet.

You can't ship until it looks good, and the longer features are in-flight the worse management feels about the team's abilities.

<comment><USER23> A utility-first compile-time CSS framework (eg Tailwind) should be a perfect fit for this scenario, on multiple levels

<comment><USER22> Two of the projects I'm thinking of used Sass or Less. The problem is on figuring out why you have black text on a black background because your CSS selectors no longer match the DOM structure, when the DOM structure is split up and/or not even HTML-like anymore.

You don't want situations where senior staff have to intervene on what should be a straightforward issue. It gums up the works.

</comment></comment></comment></comment></comment><comment><USER24> I love svelte. but now resorting to server rendered html pages with sprinkles of JS. shit I work on and I have noticed in the world doesn't really need frameworks like react, svelte, vue etc.

<comment><USER25> Same. I haven't done frontend work for a job for about a decade, but kept up to date with things like Angular/Vue/React. I was recently vountold by my wife to create a reunion site for her class. I looked up "barebones front end frameworks." Anything that began the "Getting Started" page with "npm install" I noped out of there.

I ended up with Skeleton/jQuery for the front end and PHP Slim for the backend. This is a 5 page, 2 forms, site targeted at 100 people. There's no need to SPA this, npm that.

<comment><USER26> Someone on HN recommended it to me before, so I'll just pass this along: look at intercooler JS for making individual "live widgets" on a well-designed graceful degradation site like you describe.

<comment><USER27> Also Alpine.js, which has got quite a community behind it (somehow promoted by Laravel, IIRC). It is less than intercooler, but provides timesavers for simple sites like described. A compromise between a framework and none.

<comment><USER26> No, that's not along the lines of what I'm suggesting at all.

</comment></comment></comment></comment></comment><comment><USER28> What I'd hoped to see here was why use Svelte for a _large_ web project. I get the advantages, but devising and maintaining good architecture is hard enough in the more established React paradigm. What do complex and older Svelte apps look like? This is the part that's missing for me, not pleasant DX and early- web nostalgia.

<comment><AUTHOR> 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](https://svelte.dev/examples#auto-subscriptions)

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

</comment></comment><comment><USER29> Going back to React a week ago after doing Svelte seriously since Oct 2018 is tough. Asides from the obvious stuff - Svelte's speed and bundle a size of 0: JSX isn't HTML, using weird helpers to enable a class when a JS ternary would do fine, setting state is clumsy, and there's way too much complexity if you're not already used to using React.

That said, I'm also really enjoying TS so could understand why someone may want to stick with React for a new project until Svelte gets TS.

My big Svelte project isn't public but my personal site is a Svelte app too: [https://mikemaccana.com](https://mikemaccana.com) source is at [https://github.com/mikemaccana/mikemaccana.com](https://github.com/mikemaccana/mikemaccana.com)

</comment><comment><USER30> I love many things about Svelte but after using Vue for a couple of years I wouldn't go back to single file components.

The idea of having markup+logic+styles in the same file works for small components but it gets muddy on bigger ones. It can be argued that components should be as small as possible but OTOH having to create a new file for every damn component gets old very quickly.

For the past 2-3 years I've been working again with JSX based libraries and being able to create micro components on the same JS file makes a lot more sense.

I've also gone back to regular SASS and moved all CSS outside of components (except for dynamic CSS). It works better IMO than single file components.

</comment><comment><USER31> I have switched to pure HTML/CSS/Javascript for frontend. And I am very happy with it.

I sometimes use external libraries. For example handlebars if I want to template something clientside.

But no more frameworks.

I think pure Javascript is plenty enough these days.

For those who can't live without a framework: What would you miss?

<comment><USER32> > For those who can't live without a framework: What would you miss?

The thing I miss the most is a good component and state abstraction. That's it.

I would be very happy using ASP.NET WebForms today: components are rendered 100% in the server but the state is persisted by the client using a <input type=hidden> field. The server can be 100% stateless.

Too bad it is impossible to convince anyone to pick up ASP.NET WebForms in 2020 :)

Modern backend frameworks such as Rails and Django have similar "component- ish" helpers, but those always fall short of the capabilities of both React/Vue and ASP.NET WebForms, and you have to worry about state by yourself.

Phoenix Live View is cool, but needs a stateful server, requires JS and polyfills up the wazoo. At this point I'd rather use Vue or React.

<comment><USER33> Aspnetcore Razor pages is basically web forms with cshtml, if you ask me...

<comment><USER32> That's true. I've been out of the MS ecosystem for ages, but I keep forgetting about Razor Pages.

Components in Blazor actually look like Svelte, or maybe it's the other way around.

</comment></comment></comment></comment><comment><USER34> I am on a team that has chosen Svelte to replace Riot.js. It has been an excellent experience. We have found that since Riot and Svelte have some similarities in structure and do not use a shadow DOM, we that our old Riot code and new Svelte code co-exist while we build new features and slowly migrate everything.

Our team has diverse experience with the other tools in this space. I would say that the consensus is that Svelte is far more intuitive and _fun_ than other tools.

</comment><comment><USER35> I want my templates as first-class citizens. If I have to deal with strings and weird, half-baked syntax for loops and conditionals, I'm out.

JSX really spoiled me to the point that if there isn't JSX, I don't want it.

<comment><USER36> I still feel the opposite. If your client-side 'templates' aren't just function syntax, I don't want your template system.

</comment></comment><comment><USER37> Ah, I mentioned it on Twitter [1] somewhat prompted by seeing this article, but before reading it, but:

> It's interesting that Svelte is positioned as a Javascript framework: it > seems to be practically a different language, far more so than JS+JSX.

> The downside is that it's hard to integrate with much of the Javascript > ecosystem, e.g. TypeScript.

> Yet at the same time, it doesn't fully embrace being a different language, > so it does not add features like e.g. how Elm supports pattern matching.

> It does make it an easier sell, I suppose, which does certainly count for > something. Am I missing something else?

After having read it, it does seem that the author does both consider it a separate language, but also still presents it as a JS framework. I wonder if the former isn't being underestimated?

[1] [https://twitter.com/VincentTunru/status/1237422539128868865](https://twitter.com/VincentTunru/status/1237422539128868865)

</comment><comment><USER38> I like what I see from Svelte but I'm afraid it's going down the exact same road Meteor did.

Too many options, not enough Blessed Solutions for basic things.

Take routing for example, in Svelte you have a lot of options but no real #1 "Svelte Recommends (tm)". They should solve this problem before it gets out of hand. It killed Meteor.

<comment><USER39> Sapper provides a great option for routing. I view that as the official routing solution, but there are other options too.

<comment><USER30> But Sapper is server side, no?

</comment></comment></comment><comment><USER40> Shameless plug. I've choosen svelte for webextension that will be allow you to record, replay and modify requests on the fly. I've choosen Svelte, because 1. courisity and 2. it can compile to webcomponents and also reference webcomponents in normal svelte components. I discarded the webcompoments for everything idea, mostly because clunky passing and registering events with svelte (svelte issue). There few thing that needs to be polished, like typescript support and this events handling with webcomponents, but overall, very satisfied with svelte so far (as former React guy).

</comment><comment><USER41> I enjoyed the brief period I spent playing with Svelte. I ran into some bugs with the built-in animation support when changing states (there's built in animation support for changing states!) that I couldn't resolve, and which were pretty glaring in the UI. This was 6-9 months ago, though, so it may well have been fixed by now.

I'd really encourage all front-end devs to take Svelte for a spin, if for no other reason than to see a framework really trying to do things differently. There are a lot of nice ideas in there, and the works-out-of-the-box level is admirable.

</comment><comment><USER42> > Svelte is one of the 6 JS frameworks in the (flawed) State of JS 2019 survey > — 75% have heard of it, 7% have used it, and 45% are interested in learning > more

Why is it flawed and why are you citing a flawed study? You mention that it's flawed twice but then immediately cite data from it. If you're telling me it's flawed why should I care about the data?

<comment><AUTHOR> 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.

</comment></comment><comment> awinter-py hate all frontend compile steps from a developer productivity perspective but love it from a user value perspective, especially if that enables JS-disabled browsers to more or less use dynamic sites

</comment><comment><USER43> Slightly offtopic: Why a git repo for a blog post? I guess there are some pro's: public history, PR's , but a blog has comments directly under the article for example. Forking is not expected. Ah well, extensive information anyway, good work :)

<comment><USER44> some people have been using the Issues tab to create blogs (as it allows comments)

</comment></comment><comment><USER45> Especially excited to consider a solution without huge runtime libraries (think jQuery, React, Vue). Minimizing web page sizes and enabling dynamic content (which is a mainstay in modern websites) is a huge plus.

<comment><USER46> React 16 is 2.2 KB or 34.8 KB if you include react-dom, Vue 2.4 is 20.9 KB, and jquery 2.1 is 28.87 KB.

If you're using a bundler that can create chunks, your user is at best downloading this once in a blue moon.

The reply page I'm using now is 10% bigger total than these packages and has to be pulled every time apparently.

By what metric are these "huge runtime libraries"?

<comment><USER13> > React 16 is 2.2 KB or 34.8 KB if you include react-dom

Gzipped. Uncompressed React is 6.3KB and react-dom is 114.5KB (and of course you're going to include react-dom, how else would you use it?!)

Uncompressed matters because it takes a device longer to parse more code. Particularly in a world where low end Android devices are being shipped with slow CPUs and very little RAM.

The real killer combination is React plus a giant blob of state that has to be parsed, and then hydrated into individual elements. It's a giant, giant waste of CPU time that is acceptable on my iPhone XS, but when I plug in a Nokia 2 it's horrifying. VDOM itself is needlessly CPU intense in many ways.

Even if you don't want to use Svelte it baffles me that more people don't use Preact. 9.5KB uncompressed and it does 95% of what React does. But people just don't seem to care.

<comment><USER46> > Uncompressed matters because it takes a device longer to parse more code

This is...a trivial thing to measure, at best. Engineers write way worse code that will be much bigger targets to care about that will likely never be worked on.

> Particularly in a world where low end Android devices are being shipped with > slow CPUs and very little RAM

The benchmarks for this (todomvc for example) aren't egregious, even for mobile devices.

> The real killer combination is React plus a giant blob of state that has to > be parsed, and then hydrated into individual elements.

That is a bad end-engineer design choice, you don't have to write react that way.

> But people just don't seem to care.

Because they largely don't need to: Even if the end-engineer wrote and designed things in a performant way, it wouldn't account for the slowness of business process.

<comment><USER13> So I guess the answer is "things are going to be bad, so why bother optimising?". I guess I can't really argue with a self-fulfilling prophecy like that. Not considering the size of a JS library because the business process is slow? Oh... kay? Just feels like real lowest common denominator stuff: why should I do good work when someone else isn't?

FWIW I did Lighthouse audits on React TodoMVC and Svelte TodoMVC In the performance category React gets 74 while Svelte gets 100.

First contentful paint:

React: 3.8s

Svelte: 0.9s

Time to interactive:

React: 4.8s

Svelte: 0.9s

I can't make you care about this stuff but the numbers are very straightforward.

</comment></comment></comment></comment></comment><comment><USER47> I love svelte on the personal/toy projects I've tried it on, but does someone have an example of a large-ish svelte codebase with an example of a testing pattern that they've found works?

Using mithril/vue/react, there are assertions you can make about how a given action will modify the state, and given some state, how that state will be rendered.

I've not found a good way to make assertions on the behavior of code without resorting to poking through the DOM and dealing with asynchronous behaviors.

<comment><USER48> Have you seen this treatise on Svelte testing? (Click the Table of Contents to switch pages)

[https://dev.to/d_ir/introduction-4cep](https://dev.to/d_ir/introduction-4cep)

<comment><USER47> I have not! Thank you!

</comment></comment></comment><comment><USER49> I love the idea of svelte and want to try it on my next project.

The compiler paradigm is really powerful. What if you could extend Svelte to give it knowledge of your db schema and it would figure out an optimized way to load data by generating all that code if needed. Probably something like this exists already somewhere and was forgotten about, but one can dream.

</comment><comment><USER50> How is it that 23 hours in and nobody is pointing out that svelte/sapper just freezes on runtime errors without the ability to show an error page or report them to a tracker like sentry/rollbar/etc.? This is one of the biggest barriers to being production ready or fit for use in large projects.

<comment><USER51> Wow is that true? My team has been considering moving to Svelte and not having Sentry integration would be a dealbreaker.

<comment><USER50> [https://github.com/sveltejs/svelte/issues/1096](https://github.com/sveltejs/svelte/issues/1096)

</comment></comment></comment><comment><USER22> The one thing that gives me reservations about Svelte is that the description about how code turns into web pages makes me wonder if there are any problems with code-build-run-test cycles.

I'm concerned I'll spend all of my time restarting my application to validate changes. Is this a non-issue?

<comment><USER52> I followed the tutorial ([https://svelte.dev/blog/the-easiest-way-to-get- started](https://svelte.dev/blog/the-easiest-way-to-get-started)). It starts a local server and automatically reloads whenever you save changes.

</comment></comment><comment><USER53> The lack of a large and mature ecosystem would prevent me for starting a "large" web project. Svelte is still missing UI frameworks like Material UI or Vuetify. Won't you need date range picker ? Full powered data-tables ? Treeview ? Advanced cards or other layouts ? Awesome effects / styles for a rich UI ? Svelte Material UI is a start : [https://sveltematerialui.com/](https://sveltematerialui.com/) But I will definitely give Svelte a try for my next "medium" size project.

<comment><USER54> Hey - Svelte Calendar actually has an open PR for a date-range picker which just needs a bit of testing to get it over the line. Feel free to take a look

[https://github.com/6eDesign/svelte- calendar](https://github.com/6eDesign/svelte-calendar)

As for the other components, as the ecosystem grows, these things start to appear. The advantage to Svelte is that it's super-easy to integrate _any_ vanilla component into, much more so than other frameworks. You can totally do away with nonsense wrapping projects, and just add the component verbatim.

</comment></comment><comment><USER55> does svelte have a way of hiding the .svelte components from the users on the frontend? e.g. so they cant blatantly rip the source code in your components and reuse them

<comment><USER56> Sure, it's easy: don't serve sourcemaps.

This isn't specific to Svelte though. In fact your code is much _more_ obfuscated with Svelte than with most comparable tools, since you're not serving the code you actually wrote, but rather the output of a compiler (while this is technically true if you're using TypeScript/a minifier/whatever, it's qualitatively different).

<comment><USER3> This is what makes svelte so incredibly powerful and worthy of consideration.

Not having a run time on the client is huge. But, the developer experience is exactly the same as you get from React and Vue.

You can trust this guy here, he knows what he is talking about.

</comment></comment></comment><comment><USER57> Use next.js the auto routing and ssr is a game changer, plus easy access to the huge react community

</comment><comment><USER58> As a javascript developer, I was getting nervous almost a day had gone by without another framework.

<comment><USER59> I think this mindset is outdated. Svelte itself is already a few years old.

</comment></comment><comment><USER60> Svelte is absolute trash.

It actively encourages mutability, which is a one way avenue to bugs bugs and more bugs. ie, shit like this is all over the official documentation:

      <script>
        let mutable = 1;
        function f1() {
          onMount(() => {
            mutable = /* do some complex shit here */
          });
        }
        function f2() {
          onMount(() => {
            mutable = /* do some complex shit here */
          });
        }
      </script>

      <Component onclick={f1}>
        <Component2 onclick={f2}>
        </Component2>
      </Component>

Complete non-deterministic state changes. Absolutely abhorrent stuff. Cannot believe my coworkers and others actually like using this absolute garbage of a framework.

<comment><USER61> What's wrong with mutability?

<comment><USER30> Nothing IMO but a lot of folks argue that using immutable state and functional paradigm results in more predictable applications.

Not sure if all this immutability talk in the JS community is parroting because "it's what Facebooks does" or what. Maybe it makes sense once you are building really big front end projects but personally I've never had an issue with mutable state in small to medium sized projects (less than 50k LOCs). Although I admit I've never worked on a Facebook-scale kind of project.</comment></comment></comment>


Ask HN: Best advice for starting a new job? - <AUTHOR> I'm starting a new job with a new company shortly. What's some of the best advice you have on starting a new role? Or what's worked well for you in the past? Thanks <comment><USER2> Take the time to get to know your team and those on other teams with which you will work closely. Setup lunch/coffee 1-on-1s if you can. Breaking the ice earlier will help form strong relationships that can be helpful later.

If the organization is open to change, help them figure out all the things that probably need to change, but haven't because, "this is the way we've always done it."

Document your new learnings as you onboard, and update onboarding materials to help those that follow you.

<comment><AUTHOR> Great advice thank you</comment></comment>


AT&T removed HBO from an unlimited data plan after buying Time Warner - <AUTHOR> https://arstechnica.com/information-technology/2018/06/att-removed-hbo-from-an-unlimited-data-plan-after-buying-time-warner/ <comment><USER2> Please correct me if I'm reading this wrong. It sounds like AT&T is just going to stop providing HBO free as part of the Unlimited Data Plan, not that AT&T will charge extra for watching HBO.

This is just a clickbait title.

</comment><comment><USER3> nice. can't wait for this internet to die... we need opennet/internet2/meshnet</comment>


The Chinese control the weather... - <AUTHOR> http://www.technologyreview.com/Infotech/20463/?nlid=961&a=f

<comment><USER2> _... as well as 37,000 part-time workers--mostly peasant farmers--who are on call to blast away at clouds with 7,113 anti-aircraft guns and 4,991 rocket launchers._

Well, let's hope we never have to attack China...

</comment><comment><USER3> <http://en.wikipedia.org/wiki/Operation_Popeye> This is Vietnam era tech, and the US has used it before.

</comment><comment><USER4> Wish I could upvote this one, weather modification has always fascinated me. I suspect the Chinese aren't concerned about global warming because they expect their weather modification technology to have caught up by the global warming is a problem. I wish the US and China would get in a weather modification contest in the style of the old space race; it would be really good for humanity.</comment>


You Are a Rogue Device - <AUTHOR> http://www.thestranger.com/seattle/you-are-a-rogue-device/Content?oid=18143845&page=all

<comment><USER2> Money shot:

 _The user 's guide for one of Aruba's recent software products states: "The wireless network has a wealth of information about unassociated and associated devices." That software includes "a location engine that calculates associated and unassociated device location every 30 seconds by default... The last 1,000 historical locations are stored for each MAC address."_</comment>


Html or xhtml for newbie - <AUTHOR>

I am reading the excellent Head First HTML book. It's a little bit outdated because it predicted that there would not be a HTML5 because XHTML would become the standard. Now it seems with HTML5 this is not correct and there are going to be both HTML and XHTML standards from now on. For some exploring HTML and CSS and later hopefully Javascript with a view to making some apps for mobile devices which is the standard to choose? <comment><USER2> My understanding is that xhtml is more mobile-device-friendly than html. There aren't big differences between the two. xhtml is a little stricter about having quotation marks around everything and a few other things.

<comment><AUTHOR> Thanks that suits me fine as it's easier to go with the flow of the book and I would like to try making a mobile app or 2</comment></comment>


Testing Robustness Against Unforeseen Adversaries - <AUTHOR> https://openai.com/blog/testing-robustness/ <comment><USER2> For better or worse, this helps establish neural networks that are not (or less?) vulnerable to deception via e.g. fake eyeglasses [ LINK: [https://dl.acm.org/citation.cfm?id=2978392](https://dl.acm.org/citation.cfm?id=2978392) ] and adversarial stickers [ LINK: [https://arxiv.org/abs/1712.09665](https://arxiv.org/abs/1712.09665) ].

From the post:

"We've developed a method to assess whether a neural network classifier can reliably defend against adversarial attacks not seen during training [such as Elastic, Fog, Gabor, and Snow]. Our method yields a new metric, UAR (Unforeseen Attack Robustness), which evaluates the robustness of a single model against an unanticipated attack, and highlights the need to measure performance across a more diverse range of unforeseen attacks."

Paper: [https://arxiv.org/abs/1908.08016](https://arxiv.org/abs/1908.08016) Code: [https://github.com/ddkang/advex-uar](https://github.com/ddkang/advex- uar)

If anyone w/relevant expertise is willing to share thoughts on this: please do.

For further reading: this just in -> "Robust Machine Learning Algorithms and Systems for Detection and Mitigation of Adversarial Attacks and Anomalies: Proceedings of a Workshop" (2019) an open-access publication from the National Academies of Sciences, Engineering, and Medicine: [https://doi.org/10.17226/25534](https://doi.org/10.17226/25534).</comment>


Kitty – a fast, featureful, GPU based terminal emulator - <AUTHOR> https://sw.kovidgoyal.net/kitty/ <comment><USER2> I've been using Kitty for a month now. I really like it. It's slightly less usable out of the box than iTerm 2. The default shortcuts are very counterintuitive (no CMD T for new tab or CMD W to close tab). But editing the preferences is straightforward.

I prefer it to iTerm because it's so. Damn. Fast. It's the only software (besides Sublime) I run on my laptop that actually feels like it's using the 40 years of transistor improvements I'm paying for.

I know iTerm recently added a Metal renderer but I need ligature support, which iTerm Metal doesn't have.

Maintainer has also been responsive on GitHub.

<comment><USER3> From a marketing perspective I was wondering how did you discover it one month back? Product hunt? or here itself ?

<comment><USER4> It's easy to find if you search for terminal emulators with low latency.

<comment><USER5> Different conclusion for the same article: I picked mlterm

[https://anarc.at/blog/2018-05-04-terminal- emulators-2/](https://anarc.at/blog/2018-05-04-terminal-emulators-2/)

</comment></comment></comment></comment><comment><USER6> I love this seemingly new tendency of re-building the most basic things with much better design choices than originally made in 90-s (or 70-s) — it's sometimes baffling how people are ok with using weird unintuitive tools all day every day, because it's always been this way and after spending a couple months on it everyone gets used to it.

I mean, I love how user friendly (meaning configuration and all) kitty is out of the box. That's how tools made by programmers for programmers should look like.

That said, kitty behaves a little weird when scrolling back and forth in vim — at least on my laptop with my vim colorscheme. It leaves out background of a line black until I jump on that specific line or simple refresh the screen. I wonder what might be the issue here.

<comment><USER7> [https://sw.kovidgoyal.net/kitty/faq.html#using-a-color- theme...](https://sw.kovidgoyal.net/kitty/faq.html#using-a-color-theme-with-a- background-color-does-not-work-well-in-vim)

<comment><USER6> Thank you, I just installed it and am simply playing around, so didn't actually read the docs yet. This seems to help, however redrawing is still kind of weird, with artifacts appearing when resizing windows and such. Probably has to do with laptop's quasi-GPU. Also, alt+tab doesn't switch back to kitty's window, when kitty is in fullscreen mode.

</comment></comment></comment><comment> christoph-heiss Another GPU-accelerated terminal emulator is alacritty[0].

Although it has a lot less features than kitty and really is only usable with tmux (or GNU screen, whatever), it is more or less perfect for people who want their terminal to do just one thing and that one thing pretty fast.

Disclaimer: Haven't tried kitty yet and using alacritty for a nearly a year now.

[0] [https://github.com/jwilm/alacritty](https://github.com/jwilm/alacritty)

<comment><USER8> I was pretty impressed when I found alacritty a while ago, but I stopped using it as I soon found out that pretty much any speed gain I got from using the terminal is pretty much negated from having to use tmux in order to have any form of window management..

<comment><USER9> Could you please provide more details on the speed issues with tmux?

<comment><USER10> It's, well, slow. Haven't done any measurements, but it's noticeable. To do its work tmux must be basically another terminal emulator, and it seems it isn't the fastest at it. It's still strange, neither a little context switching (tmux is an extra process in the pipeline) nor doing the terminal things should amount to more than a millisecond. I think.

<comment><USER11> I haven't had any speed issues with tmux. Maybe you have something in your config that's slowing it down?

<comment><USER12> It's extremely noticeable in certain situations on MacOS.

Use a full screen terminal with a 12pt font on a 4K display. Split the tmux window into quarters and pull up some logs in each pane. Now use the mouse to click and drag on the center vertical border; quickly resize it from left to right. The border takes about half a second to catch up with the mouse cursor as tmux repeatedly reflows all the text on the screen.

</comment></comment></comment></comment></comment></comment><comment><USER13> Side note, the author's home page is an absolute relic from the past: [https://kovidgoyal.net](https://kovidgoyal.net) , including things like provisions for 56k modems, iframes, detection scripts for IE3 and AOL, and other gems.

It even looks like he has his own pre-jquery compliance library written about 18 years ago: [https://kovidgoyal.net/scripts/VisualDocumentAPI.js](https://kovidgoyal.net/scripts/VisualDocumentAPI.js)

<comment><USER14> And most of it still works perfectly fine on an iPad Pro, in a completely new browser from the future. Good times!

<comment><USER15> On safari desktop and mobile, I get:

> W A R N I N G! Your browser is not supported by this site.I cannot guarantee > that things will work as they should. Consider downloading either Mozilla > >=1.4 or Internet Explorer >= 6

<comment><USER16> Considering Safari only exists for about 15 years, and the site is older than that, I think it does a very reasonable suggestion.

</comment></comment></comment></comment><comment><USER17> Not to be confused with Kitty, the terminal emulator.

[http://www.9bis.net/kitty/](http://www.9bis.net/kitty/)

<comment><USER18> Exactly. A bit unfortunate since this is a successor? to putty which is widely used so this name clash is kind of prominent.

<comment><USER19> Kitty is a fork of Putty, or maybe more precisely it's built on putty. I used it a lot in my previous job as we didn't have key-based auth on customer servers. With Kitty I could create profiles with login information, and where needed automatically switch user to root. Good times.

</comment></comment></comment><comment><USER20> Please forgive my ignorance: what do these terminal emulators do better than a basic terminal application, such as Terminal.app? My work with terminal is quite basic, I edit a few files, execute a few commands and sometimes cURL something. Terminal.app has some basic colors, has tabs, and works out of box without any visible performance issues for basic usage. What improvements would these emulators bring to my daily life?

<comment><USER21> You may have better font rendering (anti-aliasing support on low-dpi screens), faster rendering and scrolling, better support for terminal attributes (crossed-out, overline, italic, etc). iTerm does a lot of optimizations so it can render and scroll faster (I volunteered to add a feature to it, and I dug a bit through the code).

For instance, iTerm supports italic, which Terminal.app doesn't. Gnome's terminal (vte, actually) does support overline (I volunteered adding it to iTerm, but I'm nowhere near close), which is handy for status lines, as well. I think there is one that takes ANSI codes seriously enough to support double- height and width.

To see what's missing, you can look into [https://en.wikipedia.org/wiki/ANSI_escape_code](https://en.wikipedia.org/wiki/ANSI_escape_code)

<comment><USER22> Terminal.app is orders of magnitude faster than iTerm, or any other alternative. As in: less than a second v 30 seconds for cat <big file>.

<comment><USER23> With the metal renderer?

</comment></comment></comment></comment><comment><USER24> Why render with the GPU? I don't think I've seen a visually slow terminal emulator since 2000 and barely even in the 1990's.

Text rendering is basically just blitting cached glyph bitmaps into a buffer, and CPUs have been more than overly fast doing that for eons. And CPU rendering has none of the compatibility problems/quirks that GPUs have. I can fire up a Gnome Terminal onto an unaccelerated Vesa X11 display if my graphics card doesn't work or I haven't configured it yet.

For better responsivity I suppose a terminal that behaves like mosh would be a good approach. It would maintain the tty state in memory and only render the latest view, dropping the rendering of any intermediate diffs in the buffer. I would guess most terminal emulators do work like that these days but I haven't checked.

<comment><USER25> Input latency makes for a bad user experience. People just usually don't notice it when typing as it's so common. See [https://danluu.com/term- latency/](https://danluu.com/term-latency/) for measurements of some terminal software and discussion of why latency is bad.

I'm not sure if Kitty is using GPU specifically to minimize latency, but it would be a good reason.

<comment><USER26> I work in video and as a consequence I tend to be very sensitive to latency (I've spent more hours than I can count trying to figure out subtle synchronization issues) yet I've just spent one minute trying to detect input latency on my st terminal (which fares pretty badly in the benchmark you linked) without success. And that's running inside tmux on top of that.

That being said I think it is valuable to have a reasonably fast terminal because it's not uncommon to have applications slow down dramatically if they output a lot of information on stdout/stderr while the terminal struggles to render everything.

<comment><USER22> I would have said the same, until I recently had to boot into an UEFI shell.

Input was just so .... immediate? It's really hard to describe, but it was surprisingly obviou.

<comment><USER25> Yeah, the feeling is pretty much "the letter appears while I'm pushing the key down" vs. "the letter appears when the key returns to the top position". Both feel immediate in their own way.

</comment></comment></comment></comment></comment><comment><USER27> Best terminal I've found except for a complete deal-breaker for me: Lack of support for bitmap fonts (meaning I cannot comfortably use them in low DPI monitors), and the author has no intention of adding them.

A pity, maybe some day either the author changes his mind or Alacritty will be less buggy to make it a straight upgrade to Kitty. In the meantime, Termite it is.

<comment><USER28> Likewise, I found this as I was trying to make it work with Terminus:

[https://github.com/kovidgoyal/kitty/issues/106](https://github.com/kovidgoyal/kitty/issues/106)

Obviously using the truetype version (which isn't pixel perfect but a mess) is not an option.

Too bad. I'll stick to libvte (sakura).

</comment></comment><comment><USER29> Two simple speed tests:

        time find ~

/dev/null takes 8 seconds

alacritty takes 8.5 seconds and uses 75% CPU

kitty takes 15 seconds and uses 100% CPU

konsole takes 16 seconds and uses 100% CPU

        time for i in {1..2000000}; do echo $i; done

/dev/null takes 8 seconds

alacritty takes 16 seconds and uses 75% CPU

kitty takes 17 seconds and uses 100% CPU

konsole takes 16 seconds and uses 98% CPU

<comment><USER30> I'm guessing you're on KDE (as am I) but it would be cool to see GNOME Terminal compared also. What I got from these results is that Konsole is already good enough to not bother switching.

<comment><USER29> Yes, I'm on KDE on X. gnome-terminal does not work (easily) on my distro so I cannot measure that. I did measure xterm which takes over a minute for both tests and also stresses out X. None of the other terminal emulators did that.

Still, I wonder if the terminal emulators could use less CPU and be faster if they refreshed only with the frequency of the monitor.

An interesting insight from the tests is that the execution speed of a program can depend on the speed of the terminal emulator.

<comment><USER31> How about Terminology?

[https://www.enlightenment.org/about- terminology](https://www.enlightenment.org/about-terminology)

<comment><USER29> Terminology 1.1 takes 26 seconds and 100% CPU on find and 15 seconds and 90% CPU on the bash counting.

</comment></comment></comment></comment></comment><comment><USER32> Not affiliated, but recently switched to Kitty from iTerm 2 on OS X on my main at-work MacBook Pro and I've been very impressed. It's snappy, easy to configure and works well with my zsh/tmux setup with a few tweaks. I would love to drop tmux in favor of kitty's sessions and multiplexing, but old habits die hard, so it will take some time.

<comment><USER33> What does kitty buy you on top of tmux that is worth locking yourself into a particular terminal?

<comment><USER34> Speed.

Locking how? He can keep his tmux configuration and use it when he needs to in the future.

</comment></comment></comment><comment><USER35> Wow. This is from the guy that created the calibre ebook software.

</comment><comment><USER36> Terminal emulators have tabs/windows, tmux has tabs/windows, vim has tabs/windows. All with different keyboard shortcuts and semantics.

I wish this were all unified into a single window/tab/keybinding model. That was easy to code against and write your own interactions for.

I keep hoping I'll see a boundary-pushing project like Kitty do something new in this space.

<comment><USER37> vim-tmux-navigator[0] is probably the best thing I've installed in my terminal for transparently moving between splits. Using it has allowed switching splits to become so thoughtless that it's automatic as I move my eyes.

[0] [https://github.com/christoomey/vim-tmux- navigator](https://github.com/christoomey/vim-tmux-navigator)

</comment></comment><comment><USER38> This doesn't work on half of Nvidia-powered laptops:

[https://github.com/kovidgoyal/kitty/issues/456](https://github.com/kovidgoyal/kitty/issues/456)

<comment><USER39> Closed and locked with:

> I'm widely known for my extreme stupidity.

Loving the zero <expletives> given approach from the maintainer. Installing now.

<comment><USER40> Kovid Goyal is infamous/known to be a bit toxic, see Calibre: [https://news.ycombinator.com/item?id=8213946](https://news.ycombinator.com/item?id=8213946) (and the setuid "issue": [https://lwn.net/Articles/465311/](https://lwn.net/Articles/465311/))

<comment><USER41> He seems to be sarcastic especially when needled, opinionated, sometimes incorrect, and willing to argue a point.

On the other hand he actually fixes things.

Even if you actually were paying money for his services, which most of us are not, which would you prefer an obsequious kind person who didn't fix your problem or a dick that did.

I would take the dick every day of the week.

<comment><USER38> > I would take the dick every day of the week.

When I'm asked a question whether it's better to hire a dickhead that is an expert in some field, or a normal person that isn't an expert of this field but showing promises, I'm probably always going with the non-dickhead person.

Dickheads are hard to communicate with, they are lowering team morale, make teamwork harder so in the end expert dickheads are less valuable than non- dickheads.

</comment></comment></comment></comment></comment><comment><USER42> What I could really use would be a terminal emulator that is:

a library that I can feed data directly into (without a pty)

LGPL, MIT, or BSD

able to quickly serialize its internal state (make me a blob)

able to restore state if I feed it a blob of saved state, even across different software builds

portable to recent versions of Linux and Windows

<comment><USER43> Theres no way you can build a terminal emulator without a PTY and still expect terminal UIs (eg stuff that uses ncursors) to work.

Moreover, the session state saving is not possible either since you need to save the internal state of running programs as well as their cached output (saving the output is really very easy but it's the least of your worries given the specifications you've described).

You might also find this problem is better solved with a $SHELL replacement rather than a terminal emulator.

<comment><USER42> Yes you can. I want to hook this up to an emulator (like qemu or MAME) with an emulated serial port. That is the PTY equivalent. I'm writing this emulator.

So the emulator gets bytes from the emulated virtual machine, and then what? This needs to get fed into a terminal. While it is possible to invoke xterm with the very buggy -S option, there is no way for the emulator to suck the state back out of xterm for coherent snapshots. Simics uses xterm with the -S option. It sucks.

A library interface is required. The whole point of a library interface is to allow session state saving. Using a $SHELL replacement is way off. That has nothing to do with the problem.

So, if you were hacking on an emulator (qemu, MAME, Simics, VirtualBox, etc.) and you were trying to emulate a device with a serial port or even a modem, how would you get snapshots to contain the terminal state? To make this work, you need that state within the emulator. Passing stuff over a PTY is not going to work.

<comment><USER43> You're only solving half of the problem (and doing it in a needlessly complicated way at that). As I said, capturing the TTY output is the easy part. Storing the running state of the program that's writing to the TTY is your bigger issue. That's why I suggested a custom $SHELL (I guess there's no need to reinvent the command line so you could probably use a multiplexer instead?) that could manage the running state of the executing programs and their PTY.

<comment><USER42> Storing the running state of the program that's writing to the... serial port or whatever... is a solved issue. Most emulators and virtual machines can do this. For example, VMWare Workstation can do it. Simics can do it. Qemu can do it.

The state of an entire OS, with all running programs, gets saved. It's more complete than when a laptop/notebook does suspend-to-disk. The emulator saves the CPU registers, the RAM, the disks, the parallel port mode, etc.

The trouble is that a connected terminal is not included in that list.

<comment><USER43> There isn't anything writing to the serial port. The process of writing to the serial port is fast enough that the IO isnt the problem. What you're after is the capture of stuff that has already been outputted on the terminal and that can be captured. It's called a scroll back buffer history. Some terminals can even make that persistent.

You keep trying to reinvent terminals with features that already exist to solve a problem that needs to be fixed in the server itself.

<comment><USER42> I didn't see a "reply" link below. This is a [https://news.ycombinator.com/item?id=17949657](https://news.ycombinator.com/item?id=17949657) response.

I emulate lots of different things. I'll make up an extra-simple case to illustrate the problem.

The guest OS running in the emulator is just a bootable floppy image for testing. All it does is print a counter to the serial port, once per hour. Just after 3 hours it has written 0, 1, 2, 3. At this point I make a snapshot file named 0123.snap and let the software continue running. More numbers get printed. Eventually the terminal is showing 0, 1, 2, 3, 4, 5, 6. I decide that I wish to go back in time, so I issue a command to load the 0123.snap file into the emulator. The internal state of the emulator warps back to the point at which I took the snapshot. The CPU registers, the RAM, and everything else within the emulator are now as they were earlier. The terminal retains the old state however, because it is a separate program with no awareness of the fact that I just loaded the 0123.snap file into my emulator. The guest OS carries on from the original point of course, since that is what the CPU and RAM state dictates, so a "4" will be printed next. The terminal then shows 0, 1, 2, 3, 4, 5, 6, 4. The numbers are simply wrong. They should be 0, 1, 2, 3, 4.

I can only avoid this fate by saving full terminal state whenever I save the emulator state, and of course restoring it at the same time too. There is no reasonable way to extract terminal state from a separate terminal program. (attacking it with ptrace is not reasonable) I thus conclude that the terminal must be built into the emulator.

<comment><USER43> > _I can only avoid this fate by saving full terminal state whenever I save > the emulator state, and of course restoring it at the same time too. There > is no reasonable way to extract terminal state from a separate terminal > program. (attacking it with ptrace is not reasonable) I thus conclude that > the terminal must be built into the emulator._

It's called a "terminal multiplexer" and that is exactly what I suggested with the tmux solution right from the bloody start. I've lost track of how many times I've said this needed to be solved on the server yet you repeatedly pushed back on both points when they were made, insisting it was a terminal emulator issue on the client side.

<comment><USER42> I'm normally not a BSD user. I'm more familiar with "screen" than "tmux". To me, a "terminal multiplexer" is a physical piece of hardware. It has numerous slow serial lines to which one may attach terminals, modems, or consoles. It time-multiplexes them to/from a single high-speed link, typically by interleaving the streams of data bit by bit.

I don't see tmux being available as a library that I could link into my emulator. If it can be a library, then yes my emulator could implement the tmux protocol. This turns out to be almost exactly what I was proposing, with the terminal state implemented by a library within the emulator. I'd just be missing the user-friendly aspect of automatically popping up the terminal windows when my emulator starts, but perhaps that could be arranged by having the emulator start xterm running tmux.

This is comparable to using vnc protocol for VGA. I have this implemented, but nobody likes to use it. Everybody prefers the built-in video window to show the guest's VGA.

If you meant to not link in the tmux code though, that won't work.

Instead of insisting that there is a terminal emulator issue on the client side, I insist that there not be a distinct client. The code that tracks terminal state (cursor position, current character attributes, etc.) pretty much needs to live in the emulator. That is the only reasonable way to ensure that the state can be saved and restored by the emulator. Actually displaying this state could be done by connecting a client (annoying) or just by popping up a window.

Another nice thing about having the terminal windows built into the emulator is that they all go away when the emulator does, even if that is a crash.

<comment><USER43> To be honest I think you've decided on the worst possible way to solve your problem. But good luck with your endeavour non-the-less. :)

<comment><USER42> I think it is unavoidable. It follows naturally from insisting on user- friendly snapshots.

It is typical for emulator authors to just give up, letting the terminal be inconsistent after loading a snapshot.

So far I've done just that... but my users love loading snapshots.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER44> This is somewhat of an aside, but the fastest terminal emulator I've ever used is rxvt-unicode. I don't even know if it utilizes the GPU (doubt it), but damn is it snappy. Try it out if you're on GNU / Linux.

<comment><USER45> This nice study goes into nicely thought out detail to compare speed of emulators, I recommend it. Urxvt is not so blazing fast at latency, and it manages great scrolling speed by dropping content. (It's my current emulator of choice though !)

[https://lwn.net/Articles/751763/](https://lwn.net/Articles/751763/)

<comment><USER46> Does it drop it or simply not show it? Will scrolling back through history display the "dropped" content? If so I'm fine with that, it's annoying when you finally finish a task and pipe the results to a file just to find the bottleneck slowing you down was display refreshes.

</comment></comment></comment><comment><USER47> I've switched to kitty a few months ago and it works REALLY well. It's very fast and has the best support for ligatures I've seen in a terminal. With FiraCode, it makes code beautiful in the terminal

<comment><USER48> Despite my efforts to try FC, I always come back to Monaco.

</comment></comment><comment><USER49> I tried it on MacOS (MBP retina) and damn, it renders text awfully.

<comment><USER50> The text looks very nice on my rMBP on the built-in display and absolutely terrible on my attached 2k display.

<comment><USER51> I remember seeing this in iTerm, but it was fixed by changing the subpixel hinting mode. Is there an option for this in kitty? I couldn't find one in the config, unless it has a different name.

</comment></comment></comment><comment><USER52> About a year ago I was deciding between Kitty and Alacritty and I chose Kitty because of 2 important features it had over Alacritty: proper underline rendering (Alacritty just draws underscores) and text selection with Shift+Mouse. Kitty also compiles instantly as it's written in plain old C. The author is also very responsive on GitHub and addresses each issue quickly.

</comment><comment><USER53> Tried it out and it seems ok. It does seem quite responsive and wasn't too hard to customize. Doesn't have a lot of discoverability out of the box since there's no menus: I had to search through the config file to figure out that tabs exist and that to make one I need to enable the command. I would love a guide of some sort: perhaps a video showing some of the features and how they would fit into a workflow. I toyed around with tmux, but my current setup relies on panes in iterm. Since there's no option to transfer over, it'd be nice to see how to migrate. Looking forward to trying out the kittens later since I didn't mess with those at all.

<comment><USER54> And now I feel old. Menus in a terminal? _Videos_ explaining a _terminal emulator_? Migration guide from arbitrary terminal emulators configs? Get off my lawn! Kids these days, never having had to compile their own xterm and then seeing the light of our holy lord and saviour rxvt, and its endless man pages.

There's a huge configuration doc[1], and the homepage already does a very good job of introducing you to its features. You have to _read_ that, yeah, but maybe you can get a screen reader to read it for you. Dunno.

[1] [https://sw.kovidgoyal.net/kitty/conf.html](https://sw.kovidgoyal.net/kitty/conf.html)

<comment><USER55> Videos are the worst. No copy/paste. The only was to go back in the information flow is through a dumb scroller without any semantic addendum. It's a joke.

More importantly, making a video probably takes more time that having a nice write-up about anything.

I am 26, BTW.

</comment></comment></comment><comment><USER56> Question for other tmux users: if I do not intend to replace tmux, is this still a good choice for a terminal to run your toplevel tmux session in?

(compared to Apple's Terminal.app, which I found to be the fastest and least problematic on a Mac)

</comment><comment><USER57> Gpu powered terminal emulator? This performs almost 100x worse than Mac OS Terminal.app. Cat-ting a long file takes 100x longer to draw on the screen! Isn't it supposed to be faster if it's "GPU powered"?

<comment><USER58> "Some people have asked why kitty does not perform better than terminal XXX in the test of sinking large amounts of data, such as catting a large text file. The answer is because this is not a goal for kitty. kitty deliberately throttles input parsing and output rendering to minimize resource usage while still being able to sink output faster than any real world program can produce it. Reducing CPU usage, and hence battery drain while achieving instant response times and smooth scrolling to a human eye is a far more important goal."

From the performance page: [https://sw.kovidgoyal.net/kitty/performance.html](https://sw.kovidgoyal.net/kitty/performance.html)

<comment><USER59> That... doesn't make any sense.

<comment><USER60> I think it does if you consider "speed" as meaning response latency and perceived speed, not data throughput. From what I've read here so far, it _feels_ fast, while not killing your battery with bulk cat'ing of text. That's my take on it anyway. Just now going to download and try out...

EDIT/Whinging: Welp, scratch that, kitty requires an OS X one version higher than what apple will allow me to install. And while it _is_ an older MBP from 2010, at least it's fast and reliable. AND it has the multitude of ports that I like. And the magsafe.

I'm sure I'm venting into an echo changer, but, here goes. Why won't Apple simply provide me (an option to buy) a modern solid mid-level 15" rMBP for under $2000. I bought mine for $1700 and it came with a $200 ipod as a gift (sold on eBay).

Give me that. A rMBP, with all the ports, plus the new USB-C. They could leave out some of the stuff that's pricy.

Ya, give me a new version of what I have, and will last at least another 8 years (fully supported by MacOS releases), and price it under $2000. That I would buy. When I replace this one, I'm just going to have to buy something to linux or Windows (probably both, realistically), since I've been priced out the product I would have normally purchased and recommended.

</comment></comment></comment></comment><comment><USER61> I wish this ran in Windows so I could use it with WSL.

WSL desperately needs a good terminal.

<comment><USER62> Mintty works great for me. Their wsltty installer works wonders: [https://github.com/mintty/wsltty](https://github.com/mintty/wsltty)

</comment></comment><comment><USER63> Wow! Really like it. The windows organisation is well done. Usually just use whatever comes with Ubuntu, but this is much nicer. As an aside, had to add TERM=xterm-256color to my Raspberry Pi's .bashrc to get it to play nice when I SSH in from Kitty (otherwise commands like 'clear' don't work).

<comment><USER7> [https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors- about-...](https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-the- terminal-being-unknown-or-opening-the-terminal-failing-when-sshing-into-a- different-computer)

<comment><USER63> Thanks - missed that.

</comment></comment></comment><comment><USER64> Seems to render The Emoji Demo [0] nice and buttery smooth, though the skintone cube scene appears a tad broken. Quite impressed.

[0] [http://www.pouet.net/prod.php?which=76627](http://www.pouet.net/prod.php?which=76627)

</comment><comment><USER65> How does this compare to alacritty?

<comment><USER66> Alacritty is quite buggy and not very maintained, the author doesn't put a lot of work in except the occasional small merge. (They still haven't finished the scrollback support branch that's been open for ages).

I've switched to kitty and am much happier.

<comment><USER67> This is less of an issue if you use a multiplexer like tmux, so how appropriate Alacritty is depends on how you use it.

<comment><USER68> The big idea of Alacritty is that it uses the GPU for superfast rendering and updates. But relying on tmux for scrolling seems to be a case of "penny wise and pound foolish". Having to round trip key presses and updates through a separate and possibly remote process (tmux) just to do scrolling, introduces a bunch of latency. "Normal" emulators with built in scrolling don't have this problem. Scrolling is purely local operation.

<comment><USER69> It's not for _scrolling_ , it is for _scrollback_.

<comment><USER68> You are right. Replace 'scrolling' with 'scrollback' when you read my comment. :)

</comment></comment></comment></comment></comment></comment><comment><USER70> I don't even know where to start with this. We had terminals that were way faster than you could type or see 30 years ago. They didn't need a GPU and ran on a CPU 1000 times slower than what we have now.

If this is progress... I'm not sure I want it

<comment><USER71> They were also char based display at something like 320x240 resolution and maybe 16-256 colors.

Modern displays at 1920x1080 in millions of colors.

30 years ago a terminal was the whole display and nothing more. Now its a single window amid dozens of other windows including content ranging from high definition video to real-time rasterized 3D graphics.

Yes, that's progress.

<comment><USER72> Also, as others have noted, with many new layers of abstraction between user and system including the compositor, window manager, display manager, display server, and probably a host of others within the operating system and places I'm unfamiliar with.

</comment></comment></comment><comment><USER73> Everyone is talking about speed and latency, but how is it on battery consumption?

</comment><comment><USER74> I grew up and lived with urxvt and xterm for the longest time. I switched to Kitty full time, and I do not regret it.

I wish Alacritty had better scrollback, I'd give that a go as well. But for now, I am sticking to Kitty.

</comment><comment><USER75> Why use the GPU? Is terminal redraw latency really this big of a problem?

<comment><USER76> It is if you have very large windows display a large amount of text with plenty of redraws.

Data analysis and data science comes to mind.

</comment></comment><comment><USER77> I tried kitty very briefly, but its startup speed feels very slow. As someone who prefers using my WM to manage multiple windows, a slow startup speed is absolutely killer for me.

Edit: I did some basic tests using slow motion recording on my phone, and this is how long I found it took a few terminal emulators to start: (Recorded in 240FPS)

\- rxvt-unicode 33 frames

\- kitty 298 frames

\- lilyterm 20 frames

\- sakura 55 frames

Alacritty apparently accepts input before it is able to display anything. It took 53 frames before it would take input, and 180 frames (total from startup) before it displayed anything.

<comment><USER78> You might like alacritty[1].

[1] [https://github.com/jwilm/alacritty](https://github.com/jwilm/alacritty)

<comment><USER28> No, he wouldn't. Latency matters to him, and alacritty has abysmal latency.

[https://danluu.com/term-latency/](https://danluu.com/term-latency/)

</comment></comment></comment><comment><USER79> I've installed it and I like it. Much easier than having to install tmux and built-in copy paste. I'm not a power user but I will certainly be using this. Good work.

</comment><comment><USER80> This is the real shit [https://github.com/jwilm/alacritty](https://github.com/jwilm/alacritty)

<comment><USER81> > build: failing

:(

<comment><USER82> The build on rust nightly is failing. The stable build is fine.

</comment></comment></comment><comment><USER83> Ill give that Kitty is featureful. Not sure how many times ill need to render something i cant invoke from feh in the term, but its a neat hat trick.

but fast? on an intel haswell graphics card Im seeing input latency. Sure, its technically beautiful, but the st terminal from suckless.org is lightning fast compared to this.

update: this is on a 2015 macbook with retina running funtoo, so this may be a performance consideration specific to the hardware.

<comment><USER28> It's not that featureful. It can't even handle bitmap fonts, only slow and blurry truetype fonts.

</comment></comment><comment><USER84> The developer is of the Calibre fame. I had little hesitancy on the UI aspects of this project, but I am completely surprised. Ready to give a try.

</comment><comment><USER85> I like KiTTY on Windows. If you want it to be more visually appealing than PuTTY, I found this repository helpful: [https://github.com/yograf/kitty- solarized](https://github.com/yograf/kitty-solarized)

Clone it/download the .zip and replace the kitty.exe with a recent one

<comment><USER86> Different Kitty? This one is Linux/macOS only.

<comment><USER87> Yeah OP needs to seriously reconsider the name.

[http://www.9bis.net/kitty/](http://www.9bis.net/kitty/)

</comment></comment></comment><comment><USER88> I wish this would support easy theming so I could make it a drop-in replacement for iTerm in which I use Solarized.

<comment><USER89> Like this?

[https://sw.kovidgoyal.net/kitty/conf.html#color- scheme](https://sw.kovidgoyal.net/kitty/conf.html#color-scheme)

</comment></comment><comment><USER90> Just tried kitty on MacOS -- Loved it. The diff and icat tools are must-haves. Won't use iTerm anymore

</comment><comment><USER91> Has anyone found a way to do a visor / "hotkey window" like with visor or iterm?

<comment><USER92> Yeah, without this, it's pretty useless imo.

</comment></comment><comment> mega-tux How "bad" is libvte? [https://gitlab.gnome.org/GNOME/vte](https://gitlab.gnome.org/GNOME/vte) There are a lot of terminals using it, like my current fav. Tilix (using D lang)

</comment><comment><USER93> Echo comments on rxvt. It's blazingly fast and customisable (set fg white and bg gray8 in .Xresources). It has full Unicode support too. Firing it up on my 10 year old FreeBSD workstation is still snappier than macOS or Win10 WSL will ever be.

</comment><comment><USER94> Used (and enjoyed it) -- just wish it were in Debian Stable (or backports) already.

<comment><USER95> It will be in the next stable! You can install it from Testing or Sid.

</comment></comment><comment><USER96> I can't seem to get the config changes to show up on my install, is there something I'm missing in my setup? I update the config, save it, quit Kitty and start it up again, nothing still :/

<comment><USER97> The file is in a different location depending on OS. For example on macOS it's ~/Library/Preferences/kitty/kitty.conf

<comment><USER96> Thanks, didn't realize that :o

</comment></comment></comment><comment><USER98> How is this going to work with OpenGL's deprecation on MacOS?

<comment><USER99> Like everything else, it will probably use a shim.

</comment></comment><comment><USER100> Is there a repository for ubuntu? I tried to use the binary but don't even have scroll bars on the window, and when I ssh somewhere I cannot start a screen session

</comment><comment><USER101> 1\. no preferences window 2\. no resize option for text 3\. "Cannot find terminfo entry for 'xterm-kitty'." ie screen doesn't work in ssh

makes this hardly usable

<comment><USER95> 1\. There's a configuration file, and it's incredibly well-documented. You can simply reference the default config, read the manpages, or read the available documentation for help. See:

[https://sw.kovidgoyal.net/kitty](https://sw.kovidgoyal.net/kitty)

2\. There is a resize option for text. Hell, in my experience, Kitty seems to have the most powerful font management of any terminal. See:

[https://sw.kovidgoyal.net/kitty/conf.html#conf-kitty- fonts](https://sw.kovidgoyal.net/kitty/conf.html#conf-kitty-fonts)

3\. That's because the machine you're SSHing into doesn't have Kitty's terminfo files. That's easily fixed by running "kitty +kitten ssh myserver" where "myserver" is the IP/domain of your server. See:

[https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors- about-...](https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-the- terminal-being-unknown-or-opening-the-terminal-failing-when-sshing-into-a- different-computer)

</comment></comment><comment><USER102> Another terminal emulator for systems that have already plenty of very good terminal emulators. A version for Windows on the other hand would have been very useful.

</comment><comment><USER103> I would try it if there is a way to imitate Yakuake behaviour. The way that kitty allows to be controlled looks more powerful that Yakuake exposed dbus API.

</comment><comment><USER104> I tried this recently. Unfortunately it doesn't support bitmap fonts, so I can't use Terminus there.

</comment><comment><USER105> I live and die by my emulator(Guake) :) Can't live without it !

<comment><USER106> I do something similar. I put any tty's I use in i3wm's scratch buffer and move it to the top. A key press then pops it up like a drop-down window without an animation.

I quite like Kitty compared to urxvt, which I was using before. Just looking at cmatrix, you can tell the difference. Smooth characters dropping down in kitty, sketchy 10fps on urxvt.

The only thing that bothers me is the theme being set in the config file. For urxvt, I put the theme separately in xresources and have a shell alias to change it (which then requires opening a new terminal, but that's what I use tmux for).

Maybe I can do something similar for Kitty, haven't really read the docs.

</comment></comment><comment><USER107> Does it support transparent/translucent windows?

</comment><comment><USER108> What is this shortcut?

Increase background opacity ctrl+shift+a>m

</comment><comment><USER109> Does it have an equivalent to iterm2's imgcat?

<comment><USER7> [https://sw.kovidgoyal.net/kitty/graphics- protocol.html](https://sw.kovidgoyal.net/kitty/graphics-protocol.html)

</comment></comment><comment><USER110> How do we install the GPU without a terminal?

<comment><USER111> Software emulated gpu library backend

<comment><USER110> On that note, it would be cool if QEMU could emulate a GPU.

<comment><USER111> You can make that happen :) FOSS drivers for Nvidia/AMD/intel gpus could serve as a basis for the hardware interface you target. I would probably target an Intel GPU.

</comment></comment></comment></comment><comment><USER112> How fast it is compared to VTE?

</comment><comment><USER113> is there support for any sort of 'guake' drop down terminal mode?

<comment><USER114> The author won't integrate this for portabilities reasons : [https://github.com/kovidgoyal/kitty/issues/45](https://github.com/kovidgoyal/kitty/issues/45) "This is not possible to do in a cross-platform manner, as it depends on the details of the desktop environment/window manager. Really this function should be implemented in the window manager, so it can be performed with any window."

There are a few pointers for Linux solutions in the issue.

</comment></comment><comment><USER115> I was surprised that kitty became 'GPU based'. Then I realized it's an entirely different tool than the kitty fork of putty.

I do wish creators of these tools would search for existing names to see if they are already in use. I would not mind if they were tools with sufficiently different purpose. But this just confuses users (and potential users) of either one.

<comment><USER116> 9th issue on their tracker: [https://github.com/kovidgoyal/kitty/issues/9](https://github.com/kovidgoyal/kitty/issues/9)

<comment><USER117> Looks like its unlikely to get changed, as stated in the last comment of the thread by the owner.

[https://github.com/kovidgoyal/kitty/issues/9#issuecomment-41...](https://github.com/kovidgoyal/kitty/issues/9#issuecomment-418566309)

</comment></comment></comment><comment><USER118> Wonder how it compares to [https://hyper.is/](https://hyper.is/) \-- Hyper isn't directly bound to OpenGL, but it uses Electron, and maybe ends up in a similar place?

<comment><USER119> [https://github.com/zeit/hyper/issues?utf8=%E2%9C%93&q=is%3Ai...](https://github.com/zeit/hyper/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+slow)

<comment><USER120> Gaaaazoooks!</comment></comment></comment>


Profounder: Micro-investing? - <AUTHOR> http://www.profounder.com/ <comment><USER2> How do they get around the SEC's "sophisticated investor" regulations? Ignoring them may make follow on rounds extremely complex -- if not impossible. Also, having a polluted cap table makes subsequent raises far more difficult. [Edit: By polluted, I mean having many, many investors.]

</comment><comment><AUTHOR> Just came across these guys. Looks interesting, to say the least. Former Kiva folks involved too, so they know how to do the micro thing. Curious from thoughts/experience/feedback from other HN types that have worked with these guys.

</comment><comment><USER3> I hate to make a "me-too" comment, but I'm rather interested in this. I hope they're legit and aboveboard. Its hard to find people worth investing in.

How does this comapre to Kickstarter?

<comment><USER4> As CTO at ProFounder I'd like to think we are both legit and aboveboard. We've got a very open team and we are all very excited at the opportunity to help small businesses. The legal elements to what we are doing are complex and we see it as port of our jobs to communicate them clearly to all parties who take part.

ProFounder is different from Kickstarter in that we aren't a donation platform but an investment platform. That means that you can get the money you put in back and possibly even have some upside if the business does well. Correspondingly you as the investor take on some risk as with all investments.

<comment><USER3> The fact that you replied to me here on HN says a lot. I wish you good luck.

</comment></comment></comment><comment><USER5> I know Profounder is in very early stage, but where is the interface for investors? It's important to see how investors will interact with the site.</comment>


500 requests/s with Ruby on Rails 4 on a 5$ / month server - <AUTHOR> http://blog.wiemann.name/500-requestss-with-ruby-on-rails-4-on-a-5-month-server

<comment><USER2> Am I reading the ab output wrong or did you only make 40 requests and 13 of them failed?

Also there's no mention of what your test actually is?

<comment><USER3> Indeed

Complete requests: 40

Failed requests: 13

is far from good

<comment><USER4> And 28 were non 2xx, which is also a failure. Probably db issues since there is no way SQLite can handle 20 concurrent connections.

<comment><AUTHOR> I corrected the blog post with a correct sample size. Thanks for the feedback!

<comment><USER2> You're missing the ab output now which also hurts the quality of the analysis.

</comment></comment></comment></comment></comment><comment><USER5> What is the best way to establish optimal pool size? The article seems to gloss over this and instead mentions 'you need to set pool: 25', but I doubt this is a one size fits all solution.

Anyone have any experience profiling these sorts of things that can share some info?

<comment><USER6> You probably want to find out max_connections for your server.

Then figure out how many other connections you'll need outside your server (rails console, cron jobs, commandline) subtract that and you have your number.

I like to have about 10 spare connections.

Running

 __select name, setting from pg_settings where name = 'max_connections'; __

in postgres. I see I have 100 max connections.

So that minus 10 gives me a pool size of 90.

</comment></comment><comment><USER7> Cool write up - I never heard about Puma server. I should check it.

BTW, similar result like this can be also achieved with any RoR and jruby 1.7 (for me jruby 1.7 uses much less mem then 1.6). Threads in jruby are quite cheap. And as always database is the bottleneck but jruby is cool because you can embed BerkeleyDB in it (so open temp Berkely DB and cache things like crazy).

</comment><comment><USER8> If anybody wants to have a go at trying it themselves, the coupon "SSDTWEET" will give you $10 credit on DigitalOcean.

</comment><comment><USER9> Last time I benchmarked Puma on MRI 1.9 and 2.0 it was quite fast for most requests, but some requests took more than 20 seconds to complete. The bottom line being that it would be nice to see full ab output.

</comment><comment><USER10> Discussion from his previous post in the series: <https://news.ycombinator.com/item?id=5763282>

</comment><comment><USER11> I find a single dyno on Heroku does a good job too and costs $0 / month. So far the most traffic I've handled is 1,708 page views in an hour with Rails 4 (and a lot of action caching).

<comment><USER12> That's less than 1 request/second. Rails should be fine even without caching.</comment></comment>