Is Ruby Too Slow for Web-Scale? - <AUTHOR> https://www.speedshop.co/2017/07/11/is-ruby-too-slow-for-web-scale.html <comment><USER3> I want to add my POV here because I've been working with Rails for 6 years and recently changed jobs and moved to Python and Node.JS (and been working with Golang for the last 3 years).

One thing I would like to say is that the development experience with Ruby/Rails is by far the best out of all of these languages. By FAR.

The way you can start a project in a second is amazing, the TDD experience and Rspec integration with Rails is simply mind blowing comparing to anything else.

Express might be 100% faster than Rails but it will take you 5 days just to get something running vs what you can do with Rails in a matter of minutes. From Authentication to Authorization and all the community around these.

Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't.

Most of the slowness you are experiencing in Rails and Ruby apps is by doing poor engineering, not by Rails or Ruby itself. Big Surprise... If you query 1000 rows and bind them to the controller things will be slow.

There are things that are natively slower, JSON parsing and marshaling for example is one. It's much slower than Go for example but it's so much easier and for 99% of us, this is what matters.

I don't get the hate that Ruby and Rails are getting. Really don't.

<comment><USER4> In chronological order of professional web experience, I used PHP for 3 three years, Python for 6 years, and am about a year into Ruby. I've got tons of time in other languages and areas as well, but that's less relevant to this discussion.

> One thing I would like to say is that the development experience with > Ruby/Rails is by far the best out of all of these languages. By FAR.

So far I find Rails very sane and well-thought-out, but I really, really dislike Ruby. I realize that's a personal preference issue, but it is what it is.

> The way you can start a project in a second is amazing

This seems pretty ubiquitous to me with "batteries included" frameworks. Rails doesn't have a huge leg up here over, say, CodeIgniter circa 2009.

> the TDD experience and Rspec integration with Rails is simply mind blowing > comparing to anything else.

I very much like Rspec. One of Ruby's greatest strengths is the ability to define simple and semantically meaningful DSLs. Rspec is a great example of a good DSL.

> Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT > matter for 99% of us. It simply doesn't.

I agree 100%. Python is my preference, and not because it's lightning fast. It's fast enough that I'm almost never trying to improve performance, and when I am, my project has progressed to the point that it makes sense to scale horizontally instead of trying to make it fit into existing resource constraints.

> I don't get the hate that Ruby and Rails are getting. Really don't.

For me, it's because Ruby is just hard to grok. You have an object that's acting funny? Where is it defined? Here... here... here... some over here... Which one of those have been executed, and in what order? That sort of thing makes me want to pull my hair out.

<comment><USER5> > For me, it's because Ruby is just hard to grok. You have an object that's > acting funny? Where is it defined? Here... here... here... some over here... > Which one of those have been executed, and in what order? That sort of thing > makes me want to pull my hair out.

I hear this almost every time Ruby is discussed, but I've been building rails apps pretty much exclusively since 2007 and I've only once experienced this problem and it was due to someone trying to make the most generic thing possible to solve a relatively simple problem incorrectly.

Can you point to a specific example? Is it in Ruby libraries? Is it in the application code you are working on? In Rails?

</comment></comment></comment><comment><USER6> > So, if we've already got ~40 milliseconds of round-trip network latency in > the first place, will our users be able to perceive the difference in a web > application which renders a response in 1 millisecond or 100 milliseconds? > That is, one application will take 41 milliseconds in total and the other > 141.

Yes. Definitely. Absolutely. The users will perceive the difference. This is a slowdown of over 3X. If you're loading resources (in a variety of synchronous batches of asynchronous requests) for your web application, these slowdowns compound significantly.

Of course, the design of the web application plays a huge role, but assuming the worst (every user action triggers a request), a 3X slowdown is perceived by a variety of users.

<comment><AUTHOR> I cited decades of human-computer interaction research that disagrees with you.

EDIT: also, that paragraph is purely discussing the response times for producing the HTML document of a web application, not, say if you added 100ms lag to every JS response (which would compound, like you say).

<comment><USER7> I think one of the main datapoints is the classic quote from Amazon that 100ms of added latency reduces sales by 1%. There are similar comments floating around from other big players (Google etc) too.

edit: this is the best link I could find for now: [http://highscalability.com/latency-everywhere-and-it- costs-y...](http://highscalability.com/latency-everywhere-and-it-costs-you- sales-how-crush-it)

</comment></comment></comment><comment><USER8> No.

How about this: understand what the hell you're doing.

For 99% of the web, 531 requests a second is beyond what you need. Not everything on the web needs to respond to 7000+ requests a second. In fact most of it doesn't. Heck, most of it doesn't need to respond faster than 1 second. In my experience, most of the poor performance in Ruby web applications is caused by trying to shove too many operations into the same process and making all data "first class". This is probably in part because Rails for years didn't include a built-in jobs system.

The only thing "web-scale" means is that something serves HTTP requests through the web in a way that people find useful. If so, then any language that can create sockets is potentially web-scale, including COBOL. Beyond that requirement, there's no such thing as "web scale". All web companies like Facebook, Amazon, Twitter, Apple, etc., operate at different scales and adjust to their own needs accordingly.

<comment><USER9> "web-scale" is a fairly established term (overused sure, but established). Arguing that most sites are not web-scale is beside the point.

As someone who's spent a lot of time scaling up ruby servers (I like to think I know what I'm doing), I can say it's not ideal for any high-scale applications for a few reasons:

1) It's hard to scale: Just look the thousands of stackflow posts on MRI garage collection tuning, unicorn forking, puma clusters and RoR performance to see that people struggle with it long before any huge scale. Other languages/frameworks are often 30x faster out of the box and cause fewer headaches when scaling up (we've been using GoLang lately). Ruby is easier to write and I love it for that, but much harder to scale. It takes more effort in the long run for high-scale apps.

2) The community tends to design for smaller scales. The ruby community is awesome, but as a result of focusing on lower traffic apps and single threaded/process web servers, a lot of the gems aren't designed for high throughput or concurrency. For example, ActiveRecord's connection pooling is often painful. Also, I found a pretty critical concurrency issue in the very popular DelayedJobs gem a few years back which had gone unnoticed for years.

3) MRI has performance issues: the GIL, slow GC, slow threading and other issues make it a slow language. It's fine for a lot of use cases, but try serving images, video or doing a lot of processing and you'll quickly hit its limits.

You absolutely can make Ruby work at huge scale, but it's much harder. I wouldn't recommend it if you hope/plan to require high-scale.

<comment><USER10> 1) All it really changes is the ratio of application servers to DB servers. If you're running $40k of servers a month it might be worth it. Otherwise, probably not. At the time Twitter was struggling with scale they were also still running on a single MySQL server.

2) Rails has been thread safe since 2008. Ruby/Unicorn was serving some of the busiest sites on the internet in 2010. Go only went stable in 2012.

Connection pooling in other frameworks is usually even worse. Rails is the worst web framework, except for everything else.

delayed_job wasn't designed to be high throughput or threadsafe, but Resqueue and then Sidekiq certainly were.

3) The GIL also massively simplifies the Ruby internals for the core dev. Some platforms don't have performant hardware mutexes. Even dealing with OSX, Linux, Windows and *BSD is a nightmare.

The GC is actually really fast in Ruby 2.1+

Images shouldn't be served directly through Rails, even if dynamically generated. You're asking for a world of pain doing that.

I previously worked on a high-traffic mapping application where we generated the map tiles on the fly through a Rails app and served the images directly and we no scaling issues caused by Ruby/Rails but we did have plenty of CPU load from Imagemagick!

<comment><USER9> 1) That ratio can be 40:1+ for a lot of use cases. That adds up in costs and if you have any other limitations (DB connections) it can be a total deal breaker.

2) I said many gems, not Rails. Connection pooling in other frameworks is worlds better (GoLang's db package comes to mind). We're talking about now, not 2012.

3) Sure GIL is convenient when thinking about code, but the point is it makes high-scale hard. 2.1 GC is only fast by ruby standards. "Images shouldn't be served through rails" < exactly my point, other languages handle this with ease. If you are building a high-scale app you can choose 1 language+framework, or RoR AND another when things are big/hard/tough.

IMO, RoR (and Ruby in general) makes easy things easier, but hard things harder. A good tradeoff for some projects, but not big or high-scale ones.

<comment><USER10> 1) I honestly have not seen a ratio that high for a web service. Most of the hot points of serving a web request through Ruby are actually written in C, so on the same machine I can only serve about 2x as many simple JSON requests through Gin as Sinatra. Once you add in waiting on IO for a DB call this gap gets narrower until it basically disappears.

What blows it out to 40x? Some sort of live image/sound manipulation?

If it was an inherent problem with Ruby, you wouldn't see such fantastic performance from nginx_mruby.

2) Sure, the Go connection pool is nice, but the Go ORMs are horrible as they try and work around the warts of the language. Everything's a trade-off, really. You give up terseness and flexibility for performance.

3) The GIL is definitely not convenient when thinking about code. Threads in Ruby still require you to write thread safe code. The GIL exists to make the _Ruby VM_ simpler. Otherwise you end up in the situation of Lua, where you have to re-initialize the VM in every thread and essentially have sub- interpreters, or you build something incredibly complex like the JVM.

The 2.1+ GC usually spends less than 1% of time in collection. That's fast by any language standard. The next step for Ruby will be a method JIT. There are two promising method JITs in development using LLVM as a backend.

Images shouldn't be served through a dynamic web app regardless of your language. They should be served directly via a web server to a cache/CDN, even if you're generating them on the fly like dynamically composed map tiles. People pan away. They pan back. You don't want to regenerate the tile.

<comment><USER11> >The 2.1+ GC usually spends less than 1% of time in collection. That's fast by any language standard. The next step for Ruby will be a method JIT. There are two promising method JITs in development using LLVM as a backend.

I have read this number of times, now one Method JIT is shown, what is the other one?

<comment><USER10> [https://github.com/k0kubun/llrb](https://github.com/k0kubun/llrb)

and

[https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch](https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch)

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> There's more problems with Ruby than just speed (but it is objectively slow). Most of them caused by Rails to be honest. But who's realistically writing webapps using Ruby without Rails?

There are much better alternatives today that build upon the strengths of Ruby and leaves behind it's weaknesses. As processors become more about multi- processing, languages that leverage that are going to gain popularity.

<comment><USER13> Which alternatives do you recommend?

<comment><USER12> Leverage your Rails knowledge and jump onto greener pastures with Elixir/Phoenix.

</comment></comment></comment><comment> passer-by-123 The push to new technologies are not based solely on performance.

Rust brings a type-safe and memory-safe guarantees. Elixir brings concurrency and functional concepts that lead to clearer code. Even node.js has the benefit of ubiquity. Even if you want to debate those claims, those are perceived reasons for people adopting those platforms - just ask them. Having a more scalable and performant platform is just a nice bonus.

It is also misleading to think that performance impacts only the user experience. No, it drastically affects the developer experience too! Over the years the Ruby community has struggled with performance issues. Your application takes a long time to boot? Let's introduce a tool like Spring that works only half of the time. Your application cannot handle blocking requests? Let's push our whole design towards jobs. View rendering is slow? Let's add cache layers over cache layers (aka russian doll caching) and then good luck debugging cache expiration issues.

Even running tests is unnecessarily slow in Rails. When one test is querying the database, another test _should_ be running. I am not talking about multi- core concurrency, just simple IO-based concurrency. Extra points if a language can give me CPU concurrency too!

Those are long term issues that impact the developer productivity and increase the maintenance burden on your teams. That's without taking into account other issues prominent in the Rails community, such as abusive use of monkey patching and global state. I moved away from Rails not because I wanted performance but because I wanted simplicity and long-term productivity.

</comment><comment><USER14> I realize many will say Ruby is fast enough.

But if you're a web developer, why WOULDNT you just develop your next net new project in Phoenix/Erlang instead of Rails/Ruby?

Phoenix has most of the development bedofits of Rails, yet way better performance and scalability.

Seems like a win-win. You get a Rails like development environment without any downside of perf.

<comment><USER15> Because Phoenix's library ecosystem is probably 3% of the size of Rails'.

<comment><USER16> you also have 30 years of erlang libraries... OTP is the reason why you'd switch to elixir/otp

<comment><USER15> The number of Erlang users is a very, very small percentage of Rails users. OTP is great, but wiring up API connectors and auth systems and serializers and whatnot still takes up time.

</comment></comment></comment></comment><comment><USER17> The article isn't compelling. I'd argue most scripting languages, including Ruby are too slow for many situations. The author is thinking of one request. What if I have multiple Ruby APIs to hit? 100ms for each one adds up quickly. The frontend being a mess of many megabytes and taking 15 seconds to load is also not an excuse to make the backend shitty. Fix the front end, then the backend speed will matter. Yes, there are other considerations, but these days there are plenty of languages to choose from for the back end that offer memory management and instant reloading of code like Ruby and other scripting languages while being quite a few times faster. They also offer a chance to escape with a decent app in case the company you're working for hired a bunch of idiot architects that put in database wrapper code that takes 10x as long as the database itself to run and you don't have time or resources to rewrite the last four years worth of work in a faster language with a proper architecture. I personally cannot see choosing Ruby or any similar language (PHP, Python, JS) in the future for webdev stuff.

<comment><USER18> > What if I have multiple Ruby APIs to hit?

Then hit them with multiple concurrent threads and move on.

<comment><USER19> ... do you think available memory and CPU time do not decrease when you spawn more threads?

<comment><USER18> Use threads. They exist. Use em'. Know what threads are really good at? Hiding IO time. They're like REALLY good at it. When a thread is blocked on IO, it's not spinning your CPU. So is the thread "free"? No. Is it pretty cheap compared to re-writing an app in another lang? Yes.

</comment></comment></comment></comment><comment><USER16> My issue with Rails/Ruby (I've been Ruby developer for 4 years) is people have this tendency to write monoliths and crazy unmaintainable code.

I wish we wrote our stuff in a functional way like Elixir.

<comment><USER8> Yes, this, and mostly this. I don't know exactly where this comes from, but then again I haven't been a professional for _that_ long. Maybe it's because so much of Ruby web development is centered around Rails that someone just assumes that every new thing should just go into their existing Rails app as another model, another controller, another view, etc., instead of considering whether or not a whole domain of code could belong in another codebase or at least another process besides the same one being used by the Rails server. All the TDD in the world isn't going to prevent someone from making a bunch of poor choices around engineering or design patterns. Caching strategies can help, but they can also become crutches. At worst, they end up causing a lot of confusion when something isn't getting "updated", and some developer used a bunch of fragment caches triggered by different things.

In my experience, it's much easier to forego TDD, only write important tests, and try to divide things out into separate projects where it makes sense. That way bugs can be quickly squashed and new features can be added quickly(very little time wasted learning a bunch of complex mechanisms), unique components of a larger system can be updated & rolled back pretty independently, and you get more value out of your testing than most tests I've seen in Rails monoliths(often foolishly testing Rails features themselves). This can be done through gems or even completely separate Rails/Node/whateva applications/APIs that communicate(remember, sockets are pretty fast). If you must have a monolith, at least consider what things should be "first class" and whether or not you can afford to have things get processed in the background. Async is easy these days.

I love what Rails has done for me and what it represents, but I've become disenchanted by the lack of deep thought that it's fostered in new developers, which includes me where I was not that long ago.

<comment><USER20> This is something I think Django got much more right than Rails - <USER2> encourages splitting up of "sites" into smaller "apps", where an app is a bundled set of model/view/controller/routing and maybe a few other things. We exercise this design pattern a lot on the project I work on (we have ~350 apps in our monolith) and it's mostly a very nice codebase to work on.

I think microservices become far less necessary when the monolith is structured in this way. I'd rather have a clean API to a subsystem exposed as a Python function call than as an HTTP endpoint with all the reliability and distributed systems issues that come along with that.

<comment><USER21> This is also called "package by feature, not layer" in Java.

</comment></comment></comment></comment><comment><USER22> Obligatory link whenever this discussion appears: [https://m.signalvnoise.com/ruby-has-been-fast-enough- for-13-...](https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years- afff4a54abc7)

</comment><comment><USER23> Clickbait title aside, use whatever language will make you and your team most productive to launch your product, if you run into issues once you hit it big concern yourself with "web-scale" then.

In 15 years of coding I've run into extremely few web dev projects that tree profiling to find the issue then caching hasn't solved.

</comment><comment><USER24> It's web scale: [https://www.youtube.com/watch?v=b2F-DItXtZs](https://www.youtube.com/watch?v=b2F-DItXtZs)

<comment><USER25> "If you're willing to suffer complex code for performance, why not just write an nginx module in C?"

"node.js is is the most bad-ass rock star tech to come out since Ruby On Rails"

[https://www.youtube.com/watch?v=bzkRVzciAZg](https://www.youtube.com/watch?v=bzkRVzciAZg)

...

"What was that last part again? I could have sworn you just said Lisp"

(Yes, performance and scalability are complicated. Different solutions will be appropriate for different situations.)

</comment></comment><comment><USER26> There are more issues than just raw performance, or only raw performance. Right now, I'm working for a web services company where the vast majority of our work is via an API with a limited range of request types. We have external(locally cached) and internal data sources that all have to be queried, and dealt with before the logic can work and a response can be returned.

We're currently niggling over a few ms here, and a few there. Balancing the cost of adding more servers to distribute load. Migrating from colocation to cloud hosting in order to scale more seamlessly (iirc, over 150% growth yearly or more). Our SQL database has been a big bottleneck, moving heavy loads out of SQL and into more appropriate separate data stores.

Just because it's _only_ an extra 100ms, doesn't mean it doesn't matter, as it's not the only link in the chain. I would never, for example use rails for an API service... it's too expensive on top of everything else.

Right now we have a fair amount of C#, a bit of Node, and may consider some go for future use in pieces. It comes down to picking the right things... It also depends on what/where you're using the technology.

</comment><comment><USER27> No. If it's good enough for companies like Zendesk or Shopify, is probably good enough for you. And if your "web" somehow gets to the point in which Ruby/RoR can't make it scale, congratulations for becoming the next Twitter and then you can migrate to something else.

<comment><USER28> Fun fact: Twitch (which probably had the most ridiculous month-over-month growth in recent years, possibly since TwitteR) is in Rails...

And my favorite, Raverly (~7 mil user accounts), is done by _two engineers_ (or was, not too long ago - it's hard to get numbers on these things). Two! Talk about developer efficiency.

<comment><USER29> Twitch is moving all they can to more efficient technologies such as Go. At that scale every CPU cycle counts and any delay is perceived by users.

"We use Go at Twitch for many of our busiest systems. Its simplicity, safety, performance, and readability make it a good tool for the problems we encounter with serving live video and chat to our millions of users..." \- blog post a year ago.

Do your research before spreading old news.

<comment><USER28> I did my research. My research indicated that Twitch got set up in Rails, and first transitioned their chat client out of Ruby land.

I was not able to determine _when_ Twitch began doing this, but seeing as their first major growth spurt was _on launch_ , seems unlikely it was before they had to scale Rails to a substantial degree. I was also not able to determine what else they've switched over.

Old news is still relevant information, particularly when that news is "went from zero to ~10m on tech X".

<comment><USER29> [http://engineering.twitch.tv/](http://engineering.twitch.tv/) says: "Powered by Go" with zero mentions of Ruby.

Saying twitch "is in Rails" in 2017 is disingenuous to say the least.

<comment><USER28> Interesting. I don't know how I missed that page. I'll update my statements and opinions (and slides)....

...but Twitch still uses Ruby[1], and was still originally in Rails. It still stands as an example of scaling Rails, even if it no longer uses it.

[1] [https://jobs.lever.co/twitch/c795ef2d-2621-4383-8aa1-c85c875...](https://jobs.lever.co/twitch/c795ef2d-2621-4383-8aa1-c85c8750bfa2)

</comment></comment></comment></comment></comment></comment><comment><USER30> i dont know why people fail to understand. most of the slowness is not the language but the code.

for instance, raw php is really fast but apps like magento and wordpress slows it down to a crawl, more slower than a typical rails app.

depends per project but usually the slowness comes mostly from the abstraction with the db layer. where this means the latency to the db needs to be factored in to the benchmarks as well as to see if there are any lighter ORMs that can be used.

</comment><comment><USER31> > Languages aren't dying based on their concurrency or performance features > alone.

I'm afraid this is going to be more and more about which languages run on serverless platforms. Those companies decide which languages win.

Example: AWS Lambda is still Nodejs, Python and Java. We can hack about any language into it (I did with mruby), if we make Python or Nodejs exec it, but it's not worth the effort.

</comment><comment><USER19> Website says "The majority of web applications handle far less than 1000 requests per second."

The benchmark provided (TechEmpower Benchmark) measure the amount of requests served, but these requests are for rather easy tasks like fetching data from a SQL database and serving it. Or doing JSON serialization.

Drop in a more alghoritmically-complex and/or general-purpose task (say, compress this file using GZIP before saving it on your server), and then you will feel the speed (or slowness) of your platform. And here perhaps you couln't hit the magical "1000 requests per second" benchmark.

Objectively, Ruby implementations (on the canonical Ruby MRI implementation) are slow. Sometimes even 100x slower than C.

Taking a deep look at these graphs, where 1x is C's performance under GCC:

[http://benchmarksgame.alioth.debian.org/u64q/which- programs-...](http://benchmarksgame.alioth.debian.org/u64q/which-programs-are- fastest.html)

Ruby MRI is typically 20x to 50x slower than C.

Looking at the graph is revelaing, but in any case, for other dynamically- typed, dynamically-linked languages, here are other _typical_ figures for comparison (from the graph, relative to C/GCC, lower numbers better).

       Ruby MRI*                     20x to 50x
       Python 3                      Similar to Ruby MRI
       Racket                        6x to 12x
       ECMAscript (Node.js/V8)       7x to 10x
       Common Lisp (SBCL compiler)   2x to 5x

For statically-typed languages:

       Haskell (GHC)                2x to 9x
       Java (latest official JVM)   1.5x to 3x
       Swift and Go                 similar to Java
       C# (under .NET Core latest)  similar to Java
       Rust                         <1x to 2x
       C++ (g++ compiler)           equal to slightly slower than C
       C under GCC                  1x

* JRuby, as the graph can show, doesn't help too much, and sometimes can be 2x to 7x slower than Ruby MRI!

[http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=yarv&lang2=jruby)

At the end, for Ruby I would take the similar stance I would take with Python --- if I use it, it's because I like it. For example, I like using Python better than Js(under Node.js).

However if i was building a system that will demand performance, i'd look to other languages/implementations.

<comment><USER28> Fun fact: MRI is actually designed more around _memory efficiency_ than speed, because it's major funders are Japanese automobile companies, and Heroku; who (apparently?) care more (sometimes way more) about memory.

It's also (apparently) why MRI has such a fast startup time compared to similar languages and other Ruby implementations.

<comment><USER19> Yes, but take a look at the memory usage benchmarks (on the cited benchmarks) and Ruby is similar to Java's JVM on memory usage, sometimes better, sometimes worse.

You would need to compare "toy program" by "toy program", but for example, for the regex-redux program:

[http://benchmarksgame.alioth.debian.org/u64q/regexredux.html](http://benchmarksgame.alioth.debian.org/u64q/regexredux.html)

Bottom line is... MRI runtime is as memory hungry as a Java JVM runtime.

</comment></comment></comment><comment><USER32> ruby is not slow compare with some other languages(python, js, php) but there are some other languages there, with better PR, and better ecosystem: \- kotlin \- netcore \- swift \- go

All of them have a rails framework clone :)

ruby needs, JIT, concurrency, and some crystal magic

</comment><comment><USER33> Watch as the language and framework vultures descend on this thread...

<comment><USER19> no, i'm waiting for the vultures that think that every language and every platform is equal.

</comment></comment><comment><USER34> Is web scale like the internet tax?

</comment><comment><USER33> If the headline ends in a question mark the article is probably speculative

</comment><comment><USER35> The article tries a little too hard to defend Rails. It has very legitimate scaling issues and they are well-documented.

The author is also way too pessimistic about newer stacks and is demonstrating a grumpy-old-fart-like attitude saying that "new stacks will find new ways to jam CPUs or I/O stacks". Might be true, might be not. It's not a fact.

I also get a vibe that the author exaggerates the problems with newer stacks. And it contains way too much assumptions in the case you switch stacks.

So he says that if you migrate to Phoenix or Node.JS, then:

(1) The load on the DB will not change. True, but Elixir has a cache directly inside the VM so the I/O costs for a _separate_ memcached server are almost fully eliminated right from the get go. (EDIT: in my not-so-big Elixir/Phoenix experience so far, Ecto is still faster than ActiveRecord; but I do still admit the DB load is pretty much the same.)

(2) 20k RPM doesn't mandate 50 engineers. I've been in a team managing an app with a 12k RPM with only two senior devs. We were just fine for the 2 years I've been there.

(3) New stacks slows down development. If you don't hire juniors, this is only true for the first 2-4 weeks. I've been fully onboarded in an umbrella Elixir app containing Phoenix and GraphQL endpoints, and a total of 6 apps, for 3 weeks. I surpassed my Rails development speed for 3 weeks. Very, very bogus assumption here.

Assuming that switching a stack means you do cargo-cult engineering is disrespectful. Sure he might have seen it 200 times, doesn't mean the whole world does it. As much as I love Elixir, I was honest with myself and had to write a few small microservices in Go, and I am glad that I did because it was a perfect fit.

I have a huge respect for Nate Berkopec and was following him closely for a while. He's a really awesome engineer. But that essay left me with a bitter taste of "my constultancy might be endangered, time to badmouth the new stacks". Why do I think so? Again, too many negative assumptions about the new stacks. No real argument, just negativity.

Does Phoenix pose its own WTF moments when you migrate from Rails (or any other framework)? Sure! It absolutely does. No tech stack is perfect. The end result however is increased developer productivity -- speaking about myself and apparently thousands more out there on the internet who claim the same -- and less server costs. And these both were _measured_ over time.

If you want to use Rails, do so -- it is the perfect choice for a plethora of projects. But there is no need to badmouth alternatives especially if you don't have a case and your entire argument is comprised of negative assumptions about those alternatives.

I am disappointed with the author.</comment>


Tom Cruise wants to fix your TV by turning off motion smoothing - <AUTHOR> https://www.engadget.com/2018/12/04/motion-interpolation-tom-cruise-hdtv-4k/ <comment><USER2> Old Tom is right. Motion smoothing looks awful in movies. It doesn't represent what was actually shot, which is never good.

Some people don't care, or don't notice. Me, I turn it off. I don't want fake computer frames added to the actual frames. For me it looks unnatural, not because of "psychology" or what I'm used to, but because it actually really is unnatural due to all those added artificial flavours and colours.</comment>


Ask HN: How did you decide on a license for your open source project? - open-source-ux Was it based on whether your project was free or paid-for?
Have you ever chosen an open source license and wished you'd chosen a different one?
Have you actively avoided a particular license? If so, what were your reasons? <comment><AUTHOR> [https://choosealicense.com](https://choosealicense.com)

I'm sure this isn't exactly what you're asking for but this website is worth a visit.</comment>


Ask HN: How should the CLI be designed today? - <AUTHOR> I've long thought that the command line is just a bit rubbish, even if it is powerful.
If you were redesigning it today (2016), how would you lay it out and what it do?
E.g. collapse output. Keep more metadata on history. Built in error hints (e.g. google the error, harvest possibilities).
How should the CLI work across microservices and cloud services?
What should the graphical design be?
This is deliberately open. Looking for pet hates and ideas. <comment><USER2> My primary complaint about Unix CLI is that the commands try to do two disparate things simultaneously: outputting text for humans and generating data for consumption by other commands. In a properly designed command line ecosystem (it's far, far too late for that now), there would be good human readable output in one mode, and tools would exchange structured, already escaped data amongst themselves in another mode. Alternatively, the _shell_ would render the output for humans, and tools would just communicate in machine format.

Consider for example executing a compression command on all jpg files in a folder and below. Currently, the syntax goes something like this:

      find . -iname "*jpg" -exec gfxcompress {} \;

Naive Unix users would have expected this to be achievable by piping, but no! In reality there is a special syntax of the _find_ command that does this, and it's not completely clear how you would deal with file names further down the line, or how you would achieve further chaining. This syntax is also completely unique to the find command. You can't just plug in another data source and perform the same operation. In a CLI where tools are _designed_ to be chained, it would look something like this:

      find | match :name="*jpg" |> gfxcompress :name

In this example I used an imaginary |> operator to indicate I want something performed on every item, and I can refer to the "name" field of each directory entry directly. If I wanted to filter by time, for example, I might use the :time field instead, without any need for explicit support. If I wanted to mutate the name somewhere in the chain, I could do it. If I wanted to chain additional commands, it would be obvious how. And it would just work.

The same goes for error handling. Imagine a compiler spitting out structured error information which you could use directly in other tools without having to parse and interpret it first.

<comment><USER3> Windows PowerShell seems to offer exactly what you're looking for.

<comment><USER4> The problem with power shell is that it misses basics such as grep that command line users take for granted.

<comment><USER5> Select-String is the PowerShell equivalent of grep. [https://technet.microsoft.com/en- us/library/hh849903.aspx](https://technet.microsoft.com/en- us/library/hh849903.aspx)

<comment><USER6> Should even have grep as its default alias.

<comment><USER7> It has "sls" as its alias, even easier to type.

</comment></comment></comment></comment></comment></comment><comment><USER8> I'd basically like to have powershell. Potentially with a better introspection and attributes so that you can build a more interactive CLI. For example output size estimation + tagging local read-only commands to allow showing some output preview as you combine the commands. On-a-side display of help for arguments.

My pet hate is that commands themselves cannot tell you things about them in a structured way. There's no reason why completion and --help are somehow separate from the execution itself.

Love: context aware shell like zsh/oh-my-zsh provide. If I'm in a git project, show me a good git summary for example. If I'm in python venv, tell me about it. If I'm in some python project, extract its name from setup.py.

</comment><comment><USER9> People say Windows' Powershell using some sort of objects rather than a text stream is good.

For me I want better control over how my shell records and stores history. I want it to record more and probably not in a flat text file. I don't want it to write commands that fail to disk but I do want them in my history so I can correct my typo and run again.

I'd like lines to be rewrapped if I change terminal dimensions. I'd like more automatic pagination (rather than forgetting to use less and nuking your scrollback). I think is an issue with mintty/putty but I'd like its command history to be printed correctly after changing the terminal width.

Pet hates: terminal bells that I didn't explicitly ask for; middle click paste; the obscure terminfo file that sometimes controls the features a program uses.

<comment><USER10> Powershell is like the Java of shells: object-oriented, but needlessly verbose.

<comment><USER11> Eh, I like the Powershell angle here. By default everything is named in lengthy, self explaining names, but there's shorthand aliases for everything.

In reality, no one is using `get-childitem` instead of `ls` or `dir` (both of which are simply aliases for `get-childitem`).

</comment></comment></comment><comment><USER12> Don't google errors. Don't network anything that isn't explicitly requested to be networked. Don't give any built-in affordances for HTTP or other poorly- designed, politically-imposed protocols. I don't even know what you're talking about with microservices, as that notion only makes sense in the context of implementation details of RPC services ("Cloud APIs" in 2016 parlance).

A modern shell would:

\- Never use text as the interchange format, but rather keep binary representations in memory and link all commands in a given interaction into a single computation, doing inlining and optimization across the boundaries of what are currently separate processes communicating via pipes/IPC.

\- Know about the structure of valid invocations of commands (essentially, their type signature and the algebraic type structure of their parameters), preventing any "invalid invocation" error messages a priori. Only valid options would be permissible for tab-completion, and un-tab-completable options would give error feedback directly without executing the program.

\- Have a principled, data-race-free alternative to the filesystem for persistent storage of data, which maintains type information without preventing useful generic operations like bytewise encryption.

\- Support unicode as the only character set for text.

\- Encourage proportional fonts, so as to make box-drawing characters not work properly. An associated UI system would permits applications to refer neither to character cells nor pixels, but only to a graph of modifiable or immutable values and a set of presentation hints. Platform-specific modules would interpret these based on the capabilities of the local terminal. Full graphical applications over SSH are trivial under this model--no more "I use a shitty 1980's-era UI because that's the only thing I can export across the network consistently".

\- Allow addressing both local and remote system resources (RAM, CPUs, I/O devices) via a uniform interface, and allow dynamically attaching and detaching these from running processes, both local and remote.

\- From a more traditional shell perspective, it seems important to support "by" operations with good ergonomics. This is stuff like "sort all these files _based on the output of applying this other file-accepting command to each_ " or "filter out all paragraphs in a text file containing the string 'foo', but only print the last seven characters of each one.".

These would be a start.

</comment><comment><USER13> History should be recorded in non-volatile storage immediately, not just on clean exits (can do this in bash, but it needs to be the default).

You should be able to step though history for just arguments (can be done in bash, but needs to be easier).

Take a look at TOPS-20: it had "question-mark help"\- any time you hit ?, it told you what the next argument is for.

The terminal emulator should have inline graphical output- it should not be text only. Someone should define a protocol so that you can have full graphical programs running in the terminal emulator. When you exit the program, the last view remains in the scroll-back history.

Some plan9 things are good: network access should be in the filesystem so that you don't need special programs like wget: cp /net/www.google.com/http/index.html foo

Same with local I/O: parameters for opening a serial port should be part of the filename when you open, something like: cp foo /dev/ttyS0:9600n81

The filesystem should be extended to also be a database. SQL is ugly, but some kind of relational algebra query language should be built in:

        cat /mydatabase/name="joe" is like 'select * from mydatabase where name="joe"'

<comment><USER14> My bash history file seems to get bonked when working in multiple tabs / panes simultaneously. Is there a trick to getting history to be tracked or aggregate all of them?

<comment><USER15> [https://news.ycombinator.com/item?id=11806553](https://news.ycombinator.com/item?id=11806553)

</comment></comment></comment><comment><USER16> As an aside, in terms of design and little helpers (e.g. git/virtualenv) powerline shell really made my terminal much more friendly: [https://github.com/banga/powerline-shell](https://github.com/banga/powerline- shell)

Idea: proper graphics for data/image/video display.

I think it's an interesting idea that a terminal editor can have text only input, but the ability to draw real high-res graphical output. e.g. a canvas to draw your matplotlib diagram in the terminal output or a more graphical version of htop (with time data graphs etc).

<comment><USER17> > Idea: proper graphics for data/image/video display.

Too late. xterm already has it for a long time (I remember seeing it working as long ago as in 2003 in rxvt, and it was nowhere new thing then). See the screenshot of w3m, a lynx-like web browser: [https://en.wikipedia.org/wiki/W3m](https://en.wikipedia.org/wiki/W3m)

My today's rxvt-unicode also supports this mode.

</comment></comment><comment><USER18> Would love something that showed you how the current command was going to be parsed as an argument vector before actually submitting the command (pressing return). Would help with spacing and quoting.

</comment><comment><USER19> Do this: [https://www.gnu.org/prep/standards/html_node/Command_002dLin...](https://www.gnu.org/prep/standards/html_node/Command_002dLine- Interfaces.html)

And this: [http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html)

</comment><comment><USER20> In TCC/LE (a CMD replacement for Windows by JPSoft) there is one little feature that I miss in Powershell because I got so used to it: if you just enter the name of a folder (as if it's a command), you change dir to that folder (so no need to type the 'cd').

In Powershell you just get an error that this thing is not executable. A waste of semantic space, IMO.

</comment><comment><USER21> My biggest pet hate is the single tasking. Which is more to the nature of scripting languages. It would be great to have an event command queue.

<rant> Each time I do a npm, apt-get, brew command it irks me that all the downloads happen then they unpack, then they process. Where really it should be put on an event command queue. That way downloads can continue whilst processing is happening.

I have the same bug bear about the GUI, if I want to transcode a set of videos and move them to a NAS it's a linear process. I keep promising myself I should write a small app to get it done properly. I just wish the operating system was a little better at it. The main pain point is that if I send 10 files to my NAS it will transfer them all at the same time and take forever because of the seek time. What OS's should be doing is queuing up these things to make the transfer quicker. </rant>

<comment><USER22> * `parallel` for scripting parallelism

* `make` for scripting parallelism with dependencies

</comment></comment><comment><USER23> Easier inline editing of command args i.e accidentally executing the script when trying to enter a newline.

<comment><USER24> Current best solution: set $EDITOR to your favourite editor and Ctrl-x, Ctrl-e.

</comment></comment><comment><USER25> Hyperlinking is good, we should do more of that.

I have my urxvt configured to open http(s) URLs in my browser, but it would be nice if I could open URLs of arbitrary protocols via handlers. Similarly, being able to distinguish valid pathnames and open them in $EDITOR/$VISUAL (or perhaps via special file-type handlers) would be a nice.

Overall, I'm not particularly dissatisfied with the state of the command line in 2016. My experience has been that I make no more (or fewer) mistakes with command-line interfaces than I do with graphical ones, and that spending a few seconds thinking about what I actually want to do prevents me from using the wrong approach (i.e., a graphical or console program) to a problem.

</comment><comment><USER26> If we could start with having working ctrl-c ctrl-v that would be great :). (I know Windows improved on this with 10 but Linux is still lacking)

Other than that I wouldn't mind some graphical features, such as being able to display thumbnails of images for example.

<comment><USER27> On Linux I usually use Ctrl+Shift+C, Ctrl+Shift+V which seems to be bound by default on most terminals. Ctrl+C of course terminates the running program, usually.

<comment><USER10> Why is ctrl-C the shortcut for "terminate", anyway? I would have expected it to be something like ctrl-T.

<comment><USER28> from wikipedia ([https://en.wikipedia.org/wiki/Control-C](https://en.wikipedia.org/wiki/Control-C)):

As many keyboards and computer terminals once directly generated ASCII code, the choice of control-C overlapped with the ASCII end-of-text character. This character has a numerical value of three, as "C" is the third letter of the alphabet. It was chosen to cause an interrupt as it is otherwise unlikely to be part of a program's interactive interface. Many other control codes, such as control-D for the end-of-transmission character, do not generate signals and are occasionally used to control a program.

Also see [https://en.wikipedia.org/wiki/C0_and_C1_control_codes#STX](https://en.wikipedia.org/wiki/C0_and_C1_control_codes#STX)

</comment></comment></comment></comment><comment><USER29> It should look exactly like Powershell. Its simply a space ship compared to any other shell.

Since it is comming to Linux you should start learning it now IMO.

Xiki also had promiss. Unfortunatelly, it doesnt look like it will become mainstream.

</comment><comment><USER30> I'd like to see a good CLI design involving sandboxing-by-default, and handling object-capabilities (e.g. file descriptors) as first-class objects.

Right now, "convert a.jpg b.png" passes the strings "a.jpg" and "b.png" to ImageMagick's convert command, but that command is free to open whatever files it wants, since there's no distinction between strings vs resources such as filenames, network sockets, etc.

You can do this with pipes in simple cases, and bash has some support for this, but it's very primitive and the syntax is cumbersome.

</comment><comment><USER31> Although, through a long career, I've become accustomed to a wide variety of CLIs, I tend to agree: We've moved beyond 1999 a bit. The fact that a lot of these systems have legacy and tradition isn't sufficient. Languages like COBOL also have a long history. But now we have lots of other languages to choose from.

First off, as much as possible, I'd eliminate non-words. I tutor a lot and people think perhaps I have a speech impediment the first time I say "grep". (Yes, I know, it's not technically part of the shell. But okay how about "fi" and "esac"? Really? Why not "enod" then?)

I'd take command completion further: IDEs often have drop-downs and function signature descriptions as you move along coding. In a hypertext world with tooltips, etc, I think there's be a lot of room for those types of ideas.

I do think the philosophy of "do one thing and one thing only, but do it well" is a good one. Piping stuff together is wonderful. I wonder if it would make sense and be shorter to explain in plain English, if the "water flowed the other way" instead. For example:

"sort the output of the find result" = sort | find

as opposed to:

"take the output of find and sort it" = find | sort

(That last bit was just a random thought of the moment, just trying to think a wee bit outside of the box.)

<comment><USER18> It wouldn't be enod, it would be rof

</comment></comment><comment><USER32> I'd like to leave this cautionary tale against getting too clever from the Jargon File:

Warren Teitelman originally wrote DWIM to fix his typos and spelling errors, so it was somewhat idiosyncratic to his style, and would often make hash of anyone else's typos if they were stylistically different. Some victims of DWIM thus claimed that the acronym stood for 'Damn Warren's Infernal Machine!'.

In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed delete _$ to free up some disk space. (The editor there named backup files by appending $ to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren 't any editor backup files, so DWIM helpfully reported _$ not found, assuming you meant 'delete _'. It then started to delete all the files on the disk! The hacker managed to stop it with a Vulcan nerve pinch after only a half dozen or so files were lost.

The disgruntled victim later said he had been sorely tempted to go to Warren's office, tie Warren down in his chair in front of his workstation, and then type delete _$ twice.

</comment><comment><USER14> Autocomplete globally for every command and its subcommands

<comment><USER33> While this would be great, I doubt it will ever happen. I don't really see how this possible without support from each command being completed. And not every command is going to do this.

<comment><USER4> Maybe machine learning could help?

<comment><USER33> Going through man pages would certainly help. Otherwise you're analyzing the source code of scripts or worse, binaries. I won't say it's impossible, but I'm not convinced the effort is worth it. That said, I think it could be made much easier to make completion scripts rather than all the shell-specific stuff that exists now.

<comment><USER34> \--help would be a good thing to learn from too. But again, that assumes that --help or even a man page was implemented.

</comment></comment></comment></comment></comment><comment><USER35> Default support for control-f searching output

<comment><USER28> OSX Terminal does this (but with Command-f).

</comment></comment><comment> josh-wrale I've tried using Elixir's iex as a login shell. It was an interesting experience. The pipelining in Elixir actually makes it feel a lot like bash. In Elixir, remote shell [1], autocomplete are built in. Strings are binary. Structs help structure output for human vs machine use (e.g. see HTTPoison.get("[http://example.org"](http://example.org")) vs. HTTPoison.get!("[http://example.org"](http://example.org")). Processes are cheap. Functions are compostable. Rock on!

[http://elixir-lang.org/docs/stable/iex/IEx.html#module- remot...](http://elixir-lang.org/docs/stable/iex/IEx.html#module-remote- shells)

</comment><comment><USER36> A standard method for programs to provide help, examples, and tab completion suggestions to the shell. Right now we have man, info, --help, -help, -?, etc, and tab completion is part of the shell rather than the apps. If all of that was standardized the tools could be much better.

</comment><comment><USER37> You should have a separate output for humans, instead of having a flag for it, and programs which are the last in a chained series should default to it, but you could also redirect stuff to it in the middle of piping.

I'd love if the bash shell language was less clunky.

</comment><comment><USER38> A good CLI has to satisfy a number of conditions, IMHO:

* Human-friendly interaction:

\-- Command completion

\-- Help for all commands

\-- Doesn't need a load of APL-like runes in order to achieve anything

\-- Intuitively obvious, so far as possible

\-- Low bar for entry

* Not too verbose (something that requires the equivalent of COBOL's "ADD A TO B GIVING C" ain't gonna roll, sorry!)

* Sensible and consistent

* Embeds a full programming language - but you don't need that language to run straightforward commands

* Completely embraces parallelism without pain

\-- Including being able to spin off and manage daemon processes

\-- And having a painless way of managing (plumbing, in other words) inputs and outputs of each stage - {Uni,Linu}x shells haven't really improved the way they do this in over thirty years, and they didn't get it right the first time!

* As much as possible of the operating system's capability should be exposed, to as deep a level as possible, through the CLI

* Not tied to one operating system - inherently capable of being applied to any (or at least any common one)

My preference would be that the CLI presents a genuinely object-oriented representation of data and the programs that know how to interpret the data, plus the operating system services as well.

Microsoft's PowerShell satisfies a lot of these requirements...however, it falls way short of the "Low bar for entry" criterion, as anyone who's tried to learn it casually will have discovered the hard way.

A Pythonic shell could also be made to work (yes, I've tried using Python as a shell. No, it didn't go well), but would require a bit of nurdling to bring it into compliance with most of the requirements above, particularly the human interface ones.

A lot of questions here - a lot fewer answers, but I thought I'd throw out these thoughts for the assembled masses to contemplate, be inspired by, or tear to pieces.

</comment><comment><USER39> It'd have the features of fish shell ([https://fishshell.com](https://fishshell.com)) and would be able to pipe structured objects between programs like Windows Power Shell.

</comment><comment><USER40> I find CLI a great interface. Its just stuck in pre web days! Here are some thoughts on its design / UX -

\- contextual help. if i write a command incorrect, it should suggest correction and link to more help.

\- cloud storage of all my command history

\- be more understanding. talk a bit in natural language. Eg. show my ip address -> translated to the right shell command.

\- learn and grow automatically as the community builds more tools. Like, hey used this command but check this one out!

It is not feasible to upgrade all existing scripts to adhere to this but a wrapper shell that can provide this functionality should be very well possible.

</comment><comment><USER41> Please build me an app that lets me search "prebuilt commands" from the command line itself. I am always opening Chrome to google "how to grep recursively only files of a certain type to find phone numbers"... why can't i just search that from the command line itself and then select from the outputted suggestions?

Other than that, some random ideas..:

Probable command completion.

Possible arguments should be displayed as I type.

Syntax highlighting and beautiful margins/padding

Collapsible threads

</comment><comment><USER42> Black Screen has some pretty interesting ideas:

[https://github.com/shockone/black-screen](https://github.com/shockone/black- screen)

<comment><AUTHOR> Do you know what the roadmap is for this? It looks like they want to build a terminal, but I can't see how it's significantly different from what we've got at the moment.

</comment></comment><comment><USER43> If you have a little sense of humor, Gary Bernhardt spoke at length about what effect a better terminal environment could have on things like terminal based editors:

[https://www.destroyallsoftware.com/talks/a-whole-new- world](https://www.destroyallsoftware.com/talks/a-whole-new-world)

</comment><comment><USER44> I'd add an easy way for cli apps to expose bindings to be used from other apps. Working in a higher level language and having to rely on executing/parsing cli programs isn't pleasant.

</comment><comment><USER45> Plan9?

<comment><USER46> I used a port of the rc shell for linux as my login shell for a couple of months. I switched back to zsh eventually because rc doesn't have job control and autocompletion. The autocompletion wasn't that big an issue because it can use readline for history completion, and it can be configured so that when you type the start of a command and hit up arrow it will find the last command that started with what you typed. This can be replicated for zsh and bash, and it's arguably as good as autocompletion. I found no convinient work-around for the lack of job control, other than starting a new terminal.

How is rc better than bash or zsh? I've read the bash man pages and I couldn't figure out exactly how bash expands commands before executing them. Every time the shell see's an unquoted variable name (e.g. $foo) it will do word splitting, which is why you have to write "$foo" instead, or "${foo}bar" to distinguish "$foo" from "$foobar", etc. Add history and filename expansion and command substitution, weird syntax for control statements...

The best feature of rc is that word splitting and globbing happens once, and it results in a list of strings. There is no longer a need to quote variables all the time. No need to use filenames without spaces.

Here's what bash does:

        $ files=*; echo "$files"; echo $files
        *
        file1.txt file2.txt file3.txt
        $ # echo $files -> echo * -> file1.txt file2.txt file3.txt

Here's what rc does:

        $ files=*; echo $files
        file1.txt file2.txt file3.txt
        $ # files=(file1.txt file2.txt file3.txt)
        $ # echo $files -> echo file1.txt file2.txt file3.txt

It's similar to the situation for dynamic vs lexical scope.

[http://plan9.bell-labs.com/sys/doc/rc.html](http://plan9.bell- labs.com/sys/doc/rc.html)

[https://github.com/rakitzis/rc](https://github.com/rakitzis/rc)

</comment></comment><comment><USER47>
      int main(int argl, byte* argb)

For having just a byte* stream, not claiming this is a char, when I just have a byte of a char, and without terminating NUL character.

</comment><comment><USER48> Looks like IPython Notebook is almost an ideal way to interact with a computer (as an information processing device, rather than, for example, a game machine).

<comment><USER34> Agree. I think the plain ipython shell can go a long way now. It will pop up a graphic, and you can access the surrounding shell. In theory you can just live in ipython; I've tried it but I stumbled too much.

Next on the spectrum would be the QT version of ipython. And then of course ipython notebook/jupyter.

What _really_ looks promising is the Jupyter Lab, currently in alpha.

[http://blog.jupyter.org/2016/07/14/jupyter-lab- alpha/](http://blog.jupyter.org/2016/07/14/jupyter-lab-alpha/)

[https://pypi.python.org/pypi/jupyterlab](https://pypi.python.org/pypi/jupyterlab)

<comment><USER49> ipython shell is great for quick jobs, and is taking over a lot of what I used to do with long pipelines of cut/grep/perl -n, etc.

Being able to grab some filenames/contents with

        foo = !ls
        bar = !cat *.txt # returns list of lines

is super handy. And the real shell is always just C-z away, if I need it.

</comment></comment></comment><comment><USER50> It should understand human language. Not commands, functions and etc, just plain human language.

<comment><USER49> Down that road lies AppleScript...

trying to do even trivial things in it has forced me into the alternative hell of 'scripting bridges' and using real languages, and ultimately giving up.

</comment></comment><comment><USER4> It should have a daemon to centralize things such as command history across multiple terminals.

</comment><comment><USER4> A modern protocol to communicate with the terminal would be nice.</comment>


I Merged My One-Person Software Company with a Bigger Player (2018) - <AUTHOR> https://philderksen.com/why-i-merged/ <comment><USER2> In the text the author discusses also selling the company outright - question: how does one calculate a price for this usually? A few years' profit?

<comment><USER3> Yes, service companies usually sell for 2-3.5x annual recurring revenue (ARR), which is measured by averaging your last 3-5 years of revenue.

And you'll need to be easily replaceable.

<comment><USER4> Recurring revenue or profit?

<comment><USER3> It's almost always revenue, but I'm not sure why.

I'd pay more for a business doing $500k in revenue with $250k profit (50% margins) than a business doing $1M in revenue with $100k in profit (10% margins).

<comment><USER5> Usually it's dependent on the person selling (or their advisor). If a company is very profitable (e.g 50% margins) then an earnings multiple makes sense and the advisor will essentially present the company in such a way that it's pretty clear to the potential buyer that they're expected to think of valuation in terms of profit multiple. Incidentally, lots more buyers out there are comfortable doing that then revenue multiple. However, a revenue multiple has become the norm for companies with very highly recurring revenue (e.g. SaaS) and where the company has been run for growth instead of profit. There are many fewer buyers who will do that though, and getting leverage for deals like that is harder (a big driver of returns for some funds)

<comment><USER6> No sensible buyer (i.e. not strategic) is going to pay high revenue multiples for a private illiquid company. Exceptions to this might be when they have some advantage (existing customers etc) to sell to. But nearly all PE shops overpay on large deals.

<comment><USER5> By strategic, I don't mean "sensible" or "smart", I mean it's a buyer where the asset is considered strategic, hence it would always fit under your "when they have some advantage" umbrella.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I want to make a minor point that is not a critique but more a statement so first of all, congratulations on your success!

I think we as a society need to stop referring to single member entities with no employees (meaning a single, sole person) as a "company."

"Business" seems like a better term, or even just "product" if that's what you're selling. But "company" naturally implies multiple people, which lends credence to the business as it means the business can support more than one income.

<comment><USER8> Not only is this completely wrong from a legal and business standpoint, why would we even need this as a society?

<comment><USER7> I find the term personally confusing when only one individual is involved. Most definitions of the word include multiple people. It would seem that's an unpopular opinion here. Meh, can't win them all.

<comment><USER9> It's about establishing and limiting legal liability. Being able to establish a solo business as a company means that you don't lose your house and possessions if your company fails.

<comment><USER10> There is very little liability protection for a single-member company. You are usually going to be personally liable for your actions, and can get sued individually along with the company. Incorporation / LLC does not protect you from acts where you are also personally liable, and it does not shield your personal assets in that case either.

Edit: in the US, that is.

<comment><USER6> This depends on the country. Most (single member) companies in EU countries have excellent protections in place for directors and shareholders as long as you don't do anything illegal.

<comment><USER11> This.

For Canadians: [https://www.ic.gc.ca/eic/site/cd- dgc.nsf/eng/cs06641.html](https://www.ic.gc.ca/eic/site/cd- dgc.nsf/eng/cs06641.html)</comment></comment></comment></comment></comment></comment></comment>


Ask HN: How to promote side project being a developer with no marketing skills? - <AUTHOR> I've made a few side projects during the last years. Most of them are not longer online. I built this one during the last Xmas: https://www.coderlevel.com/ and I'm currently making this one: http://www.transparentstartups.com/
Unfortunately I'm terrible at promoting those projects or websites, so after a few months of work I usually end up giving up about them.
I find Software Development reasonably easy in general. I can convert my ideas into MVPs in a few weeks. However I struggle a lot with the Marketing side of it.
Have you been in the same situation in the past? How did you overcome it? <comment><USER4> I found this helpful. [http://devmarketing.xyz/](http://devmarketing.xyz/)

It was just an ebook when I bought it but now its has videos as well. It is a quick no-nonsense read that gives you a good foundation to work from.

<comment><USER5> Hey, I'm the guy behind that site ↑. I just checked out transparentstartups.com, and have a few tips that might help you:

1\. Identify _why_ you're building the project. Do you want to earn $100,000 in revenue? Build a public profile? Grow an email list for future projects?

2\. Determine _who_ exactly your project is for. Is it for investors? Aspiring startup founders? People spying on their competition?

3\. Clearly articulate _what_ that audience's major struggle is. Why would they visit transparentstartups.com? How does your site make them better? How does it improve their lives?

4\. Cater all your landing page copy to _your audience_ , _their primary struggle_ , and how your site makes them _better_.

5\. Figure out _where_ those people hang out. In your case it's here on HN, Product Hunt, certain Reddit sub-reddits, Slack groups, etc... Find those communities, join, and share your story (you're actually doing a good job in this thread already). Look for ways you can answer questions on the topic of startup revenue, and point people to your site when appropriate.

These 5 initial steps form the foundation for everything that comes after.

If you understand: _your motivation_ , _the people you 're looking to help_, _how you 're helping them_, and _where_ they hang out, you'll have everything you need to start promoting your project.

<comment><AUTHOR> Hey Justin! Thank you very much for your time on writing this great comment. You made a good point here so I'm going to follow your advice around those tips.

At the moment, the only thing I know for sure is _WHY_ I'm building it. Curiously, I did read some time ago your excellent post about the "The freedom ladder" ([https://justinjackson.ca/freedom/](https://justinjackson.ca/freedom/)). I realised I needed to startup from the bottom. I'd say I'm in the 2nd or 3rd step of the freedom ladder, so I aim to: Make a small project, Release for free, Help people and Build my audience. Obviously, it would be nice to get some revenue later, so I can dedicate my full time to help others with my project, but that's not a priority for me at the moment.

I'll continue working not defining those points. I'll also definitely check your book and related new interactive course.

Great thanks!

Rafa

</comment></comment></comment><comment><USER6> I have been in exactly the same position a number of times over the years. One day I realised that the reason I gave up promoting them is that I never really knew how my marketing efforts were doing so it always felt a bit futile.

This actually inspired my current project, which is all about measuring the results of your marketing ([http://flockmetrics.com](http://flockmetrics.com)).

I think several things are helpful here. Understanding the key benefits of your product and figuring out who will most benefit from those features.

Once you know that you need to figure out how to explain your product in a way that those people can understand how it helps them and then you need to find those people.

I personally have found once I've been through that process and can see that I have a product that will make peoples lives easier it motives me to want to get the product to those people.

<comment><USER7> It's sad their pricing model punishes you getting more users so harshly. It's quite expensive for only 1000 new users.

<comment><USER6> The pricing is based on the number of signups per month, so that's 1000 new users per month. Do you feel like that pricing wouldn't work for your situation?

<comment><USER7> Maybe it would be worth it for startups with a pricing model similar to yours where each signup provides large revenue, but for a startup that has a very low value per user and needs to have large growth it is not worth it.

<comment><USER6> Yeah, that's interesting. As you say, the pricing was based on looking at the numbers of signups per month for SaaS startups.

How to make that work for non SaaS startups, I'm not yet sure.

<comment><USER7> You would need a totally different pricing strategy, but whether that's a smart business move is up to you to decide.

</comment></comment></comment></comment></comment></comment><comment><USER8> Everyone knows SPI likely has BS numbers made from very creative accounting. I wouldn't doubt that, that's the case with many of them. I'd be interested to know how much they actually make. I think that this type of thing - <USER2> beyond superficial aggregation or testing - would keep your traffic there.

Anyway Nathan Barry, the founder of an email marketing company Convert Kit - <USER3> company on your list, says it pretty well: the best way to drive traffic to your products is to first drive traffic to yourself.

[https://vimeo.com/95680313](https://vimeo.com/95680313) \- A talk by Nathan Barry (Check out that Vimeo account for more talks from founders)

Driving traffic to yourself is typically done with content marketing. Here's a podcast from Empire Flippers - a company on your list - interviewing the founder of another company on the list, WP Curve. [https://empireflippers.com/wpcurve/](https://empireflippers.com/wpcurve/) (Note that podcasting and blogging is Empire Flippers' form of content marketing, and a big reason why they're as big as they are)

And here's an in depth guide by Neil Patel [https://www.quicksprout.com/the- advanced-guide-to-content-ma...](https://www.quicksprout.com/the-advanced- guide-to-content-marketing/) (Quicksprout, which seems to be an umbrella company for niche sites, also looks like it has transparent revenue btw)

In closing, I'll reiterate that it's probably most important that, like Y Combinator itself says, you build something that people want.

You can shoot me an email if you want. I'm a willing wall to bounce ideas off of. ryanacalvo /at/ gmail

<comment><AUTHOR> Hey, thanks for the great info. This is my main focus right, build something that people love. So far the response from the audience about the idea is being great but I really need to grow this audience and spread the word, otherwise my free/social model is not going to work.

Btw, I realised this kind of content marketing is very popular nowadays, for example today I was reading this post ([https://beanninjas.com/blog/how-dan- norris-built-a-7-figure-...](https://beanninjas.com/blog/how-dan-norris- built-a-7-figure-wordpress-productized-service-business-in-18-months-with- zero-advertising/)) which is from a Transparent Startup talking about another one, yeah, interestingly both are featured on TransparentStartups.com

<comment><USER8> An interview with Dan is in the second link I gave.

Dan Norris, the Bean Ninjas team and the Empire Flippers guys are all part of a mastermind called the Dynamite Circle - which was created by these guys: [http://www.tropicalmba.com/profitable-niche-selection-rip- pi...](http://www.tropicalmba.com/profitable-niche-selection-rip-pivot-jam- redux/) (Link as an episode on niche selection. They have over 300 podcast episodes).

What is your target market with TSps? Where is the monetization? Why can't you login with google? What are you sending them weekly?

</comment></comment></comment><comment><USER9> Devise a way to find someone to do it for you, someone who knows what he is doing. Don't try to do marketing yourself. Yes, you could probably do it if you worked hard enough and long enough, but the same could be said of open heart surgery. It's not an efficient way to do things.

<comment><AUTHOR> It makes sense. I'm learning a lot doing it myself and I'm actually getting some contacts / networking. However sometimes I feel like I not advancing with my project development as quick as I should because I spend most of my time hooked on reaching people (on Twitter, HN, PH, Reddit, etc.).

</comment></comment><comment><USER10> Transparent Startups looks awesome.

One way is to build projects for an audience that you either know or can reach. That might be something local in your city, HN, etc.

Another thing to consider is what your goal is — do you want regular users, paid users, newsletter signups, just feedback, etc?

There's also a regularly recommended book called Traction [1] that you might find useful. One of the authors is the founder of DuckDuckGo.

[1]: [http://tractionbook.com/](http://tractionbook.com/)

<comment><AUTHOR> Thanks for your comment. I'd love to have regular engaged users - that will keep me motivated to continue with project. Revenue might come later. I've added this book into my reading queue.

</comment></comment><comment><USER11> Notice how in the replies many people said "I built a site .."? One of the ways that you promote your site is by talking about it everywhere, especially on posts like this.

Of course I'm not advocating spamming forums, or message-boards, but if you find any topic or group which is relevant to your (potential) users you do need to mention it.

As a concrete example if you're ever needing easy to update DNS hosting you might enjoy _my_ site too [https://dns-api.com/](https://dns-api.com/) ;)

</comment><comment><USER12> Nice post. I would add that for engineers to become true marketers, if they want to, it does require some non-trivial mindset shifts [http://myessayshelp.org/](http://myessayshelp.org/)

</comment><comment><USER13> My side project Nucleus Digest [https://digest.meetnucleus.com](https://digest.meetnucleus.com) index of great startup articles.

I promoted on Product Hunt, HN, Relevant Subreddits.

Ongoing: publish content on twitter, point resources to HN, Reddit, GH community questions etc.

<comment><AUTHOR> I recently managed to get a "successful" (> 500 votes) launch on ProductHunt as well. Got a few feedback and seems people loved the idea.

However I feel I need constantly keep posting and commenting everywhere about the site to keep the momentum and some visits.

BTW, I like your Nucleus Digest project. Nice work!

</comment></comment><comment><USER14> I've found a person that's good at teaching and we're doing weekly classes. It might not make me a marketing guru, but surely will increase my ability to hire good marketing freelancers.

</comment><comment><USER15> I feel the comments that you need to hire or partner make sense. If the latter you might feel you are giving a chunk of the business away but if you are walking away anyway you're already loosing 100%.

Most importantly you should find a good marketer. Like anyhting there is a buch of snake oil being sold in marketing expertise and ability. I wrote up these points previously for what I've found as a marketer finding/actuating good people;

1) Look for someone that has experience working big and small companies. Big brands will train comms, project management, procedure and how to think at scale. Small brands give the 'getting it done' skills, generalist experience and show they can get technical/dirty hands. Larger brand experience typically looks more impressive but often work has been project management for agencies and doesnt suit hands on efforts or creativity. Likewise if you're business is big enough to run agencies if someone has always been hands on they often struggle as project managers and understanding how to communicate needs in a way that translates well downstream.

2) Dig into exact contributions for past roles. Ask for logic that lead to decisions. Often marketers talk about great campaigns results but really they were a body in a room with little input. Dig for detail and motivations to decisions and you will find out who is who.

3) Look for initiative with intelligence. Many solid looking marketeers repeat what is always done, optimising here and there. That suits some roles and businesses. There's an unrecognised value in the solid citizen employee. But for smaller business looking for exceptional results you need someone who will see the world independently of the current enviroment. This is someone that will deliver results vs turn wheels for the sake of it. Ensure they have this ability to spot entirely new oppurtunity and deliver on it.

4) Experience counts. It's easy to be attracted to enthusuasm but confidence/enthusiasm and ability are often confused. Look for someone that has done things. When looking at people with higher level expereince ensure they can get thier hands dirty. Make sure they have the ability to learn and adapt vs puely strategise.

5) Don't go cheap. I often see startups advertising low paid roles a couple years experience, while they pay for experienced developers. Half the price sounds great but they will bring a fraction of the value.

6) Find someone that can analyse data vs report it. There's a big difference in the 2 and the former is surprisingly rare.

7) Avoid anyone that shows narcissistic tendency or is generally 'me' focused. This personality tends to be bad comms people (especially with social) as they see the world from their POV, not the customers. Also your risking a tough working enviroment. Look for things like how they delivered on a job they felt was wrong or lacked value as well as the usual egocentric viewpoints when they discuss marketing examples.

8) Look for someone that lives marketing beyond thier job. A person that can talk about companies beyond their own and has interest in the wider industry and technologies vs focusing only on thier job.

9) Dont stress about direct inductry experience. Unless there is incredibly niche market knowedge or contacts needed a good marketer will be good regardless of product.

10) Sales and marketing are not the same thing. Know what you need. They dont often come all-in-one.

11) While not an absolute I usually check linkedin contacts to skill endorsements ratio. Typically this ratio is higher for the people I know are good marketers. I wouldn't make my decision by this but is seems one of those soft indicators.

12) When you interview give a 10min exercise before to discuss and cover up real-time actual skills. E.g. show them some relevant to role campaign materials (e.g. landing pages/EDM's) and ask them how they would improve. Ask them what they would do with $50k. Typically I add in some spelling/grammar mistakes to also look for attention to detail as it tends to be a 'you have it or you dont' skill (like initiative) and not something you can train up.

Once onboard;

13) Give marketers product input. They should have their finger on the customer pulse and valuable views on what sell/motivates users. Dont let tech side shut out marketing.

14) Make sure they have a budget. This goes well with the above point. Generally I'd say a 10-20x marketing salary would be a good rule of spend if bringing a permanent marketing role in.

...hope that's useful...

<comment><AUTHOR> Hey. Many thanks for writing this great comment. I'm in that point where I'm still validating the idea while keep building the basis of the product. Once I feel I have a good product that I can monetise, I'd go for your advice of hiring or partner with someone experienced in marketing. Will definitely follow those tips!

</comment></comment><comment><USER16> It depends on each case. On my case, I send email messages for possible customers, one by one. The conversion is really high.</comment>


Making Netflix.com Faster - <AUTHOR> http://techblog.netflix.com/2015/08/making-netflixcom-faster.html <comment><USER2> The code may be faster but the user experience continues to get slower, i.e., it takes more time than ever to find something worth watching. The recent UI changes simply disguise the fact that there are less titles available. Especially movies. Lots of filler, straight-to-video content that never got theatrical exhibition because the content sucked. No way to filter it out. No way to tell Netflix I really do NOT want to see this, I will never watch it, I really am not interested. Netflix will continue showing these unwanted titles to you. This is not speeding up a user experience. This is not making Netflix faster. And the user experience is really the only thing that matters.

<comment><USER3> The lack of titles is the fault of the studios. Not much netflix can do about it. Which is why they are increasing production of their own content. From a UI/business perspective many people have argued that it's always better to show a user something than nothing. "We don't have the movie you are looking for but here are some you might like" is better than "We don't have the movie you are looking for."

<comment><USER4> For anyone curious as to why "the studios" are not giving their titles to Netflix is because they are developing their own, independent Netflix's (i.e. Comcast is has internet TV at tvgo.xfinity.com).

<comment><USER5> Comcast makes the mistake of using their online streaming as leverage to tie people to their cable subscription model. I wouldn't mind looking into subscribing to their streaming, but I'm not interested in cable TV so they're out of luck. IMO this gives Netflix the advantage for now at least.

<comment><USER6> Comcast can charge a crapload of money for cable.

If they offer internet services at netflix prices and are highly successful (lots of signups) - if this allows a small fraction of their cable customers to cut ties, Comcast loses money.

</comment></comment></comment></comment></comment><comment><USER7> They need to make Netflix work first otherwise it'll just fail faster. Netflix has been broken on the Nexus Player for a long time. Let any show run to the end and it logs you out.

<comment><USER8> Another Google platform with little to no support only a year after its release? I am shocked, _shocked_. This has _never_ happened before! /s

In all seriousness though, have you contacted Netflix support? They have seemed really responsive in the past.

</comment></comment><comment><USER9> Kudos for not using the word 'isomorphic'. Most people use it (in the context of JavaScript) without understanding what it really means: [https://en.wikipedia.org/wiki/Isomorphism](https://en.wikipedia.org/wiki/Isomorphism).

<comment><USER10> "Universal" is the new "isomorphic": [https://medium.com/@mjackson/universal- javascript-4761051b7a...](https://medium.com/@mjackson/universal- javascript-4761051b7ae9)

<comment><USER9> > a word that describes the same code but running in a different environment

Uhm, that's a wrong way to think about it. The same code can't run in a two different environments. If it does then it means that the environment is the same! The question then becomes what is an 'environment'.

Once you start explicitly tracking what the dependencies of your code are, in terms of language/runtime support, external libraries etc, it becomes very clear what the 'environment' is (though JavaScript as a language is exceptionally bad at expressing these dependencies). If your code runs in Node.js and latest Chrome, then the 'environment' is ES5 or even ES6. If it also runs in IE7, then the environment likely is ES3. If your code also needs access to the DOM and WebWorker APIs, as well as underscore, then the environment is ES3+DOM+WebWorker+underscore.

If only we had support in the language and/or tooling around it to express these dependencies and warn us if we try to use some code in an environment that is unsuitable for it...

</comment></comment></comment><comment><USER11> Great example for why you might actually want to use node.js: being able to ensure your rendering code runs identically on the client and the server. That's something no other language can offer as cleanly or natively for the next few years.

<comment><USER12> scala + scalaJS IMHO does it better right now (with a lot more type safety and a lot more performance on the server)

<comment><USER13> You can't actually run a JS framework faster from within the JVM than you can in V8. And if you're writing all your code in Scala, then you're losing the productivity benefits of having a real UI framework written in JS.

<comment><USER12> I think you are missing the point.

My server code is running Scala on the JVM on the server, which is JITted down with all the magic of the JVM into native, and running full steam.

My client code is cross compiled javascript that the browser does it's thing client side.

The magic is:

1) Both parts are the same codebase, I can share data objects and logic between platforms

2) I get actual static typing on everything. Not some kind of fake static typing like coffeescript. So just the fact that my code compiles makes my code roughly equal to a mess of Javascript with a bunch of tests hitting the happy path.

3) I get to write in an actual decent language, not Javasript, the worse language to ever write in.

Javascript is the new assembly. It's great, but I never want to touch it! If I can touch a higher level language, why wouldn't I?

</comment></comment></comment></comment><comment><USER14> I'd be interested in seeing some actual numbers for their "time to interactive" metric. As far as I can tell, this article just says that they're monitoring it, not what x% improvement they've seen.

EDIT: Forgot about this at the top:

"The impact of this effort netted a 70% reduction in startup time" \-- So is this the same metric?

<comment><USER15> Eh... I think they're different. The startup time is probably the most- improved metric that's why they dropped the 70% figure. Maybe they hint at the "time to interactive" measure as a concern for the future for practical reasons. For example, startup time is probably way before the page is ready for user interaction (video playing, buttons clickable, etc.), yet the "time to interactive" is probably the most important metric to the everyday user.

<comment><USER16> Hi, author here.

Apologies for not making this more clear in the post. The 70% reduction is for time to interactive (tti).

<comment><USER15> Got it. Thanks for following up.

</comment></comment></comment></comment><comment><USER17> I love Netflix but hate using their website. It's a constant experience in annoyance. It's slow, buggy and gets in the way of discovering new content. (Chrome on Linux on an older Atom processor -- yes I know that this is a rubbish spec but other non-webapp media consuming methods work just fine.)

What about a cross platform libnetflix and let us build our own native apps? (Like spotify do.) Or even allow integration into e.g. Kodi media centre.

<comment><USER18> Even with a gaming PC, anything graphical on Linux doesn't feel as snappy as a Windows PC, with a fresh install. (OTOH on Linux, every filesystem operation feels 10x as fast..)

<comment><USER17> I think my problem is more netflix.com or possibly web app specific. Desktop apps work just nicely.

</comment></comment></comment><comment><USER19> For all the people complaining about the UI on netflix, there is a great alternative interface @ www.instantwatcher.com . Site is written in Haskell, and is quite snappy.

</comment><comment><USER20> And yet they still fail to address the most irritating aspect of their video UI -- all too often the video timeline controls remain visible while movies are playing and don't go away. This has been going on for _years_. They seem incapable of combining the mousemove event and a timer to automatically hide the controls...

<comment><USER21> Across various browsers and operating systems I have never encountered this... As long as my mouse isn't hovering over the controls they work perfectly for me.

</comment></comment><comment><USER22> Probably not the place to bring this up, but I am having so many issues with Netflix app on xbox 360 lately. I'll hit play on a title, it'll load to about 15%, then stop and take me to the "choose profile" screen. Anyone else seeing this?

<comment><USER23> You're right. This is not the place to bring this up.

EDIT: OK. I guess this is the right place so, my son's XBox hangs when switching between game playing and watching Netflix. Does anyone know how to fix that?

</comment></comment><comment><USER24> So node.js can replace Java/Tomcat? I guess I'll have to pinch my nose and somehow start liking JavaScript. Typescript looks good, that might make it palatable.

<comment><USER25> I imagine a common architecture for universal apps will be to just use some sort of thin Node.js app to perform the actual app rendering, and have it communicate with a separate API app written in whatever language is most appropriate. Static files could either be served by the Node.js app, or even a different source.

And these days ES6/ES7 makes Javascript very palatable indeed. Check it out :-)

<comment><USER26> That's exactly how you do it :)

You have one 'Universal Application', and then you have two small entry points: \- server.js is a small (express) server to send a HTTP response to the client (server bootstrapping) \- client.js renders a page and the mounts it onto a DOM node.

To get around the issues of database access, it makes it a lot easier to put all of that into an API that can be accessed by the server and the client.

Here's a very small project I build (and am continuing to build) to learn about this architecture [https://github.com/joshhunt/reactapus](https://github.com/joshhunt/reactapus)

<comment><USER24> For a non-signed in session I can see some advantage in improving the swiftness of implementing supporting changes on the server for the client developers. For signed in sessions, you can't get around the database and an API update for it when the client needs some new feature or access so in the signed in case; I think the benefits of this nodejs part would be diminished.

<comment><USER26> I'm not sure if I quite understand your comment.

You can still use authentication with an API... You don't need direct access to the database to do that.

</comment></comment></comment></comment></comment><comment><USER27> Beautiful use of modern JS development techniques: client-side rendering, isomorphic JavaScript and smaller more-efficient libraries.

Even better to see these techniques applied appropriately, instead of slathered on to the point of being detrimental.

Also, +1 for using jQuery and being proud of it! :)

<comment><USER28> > Also, +1 for using jQuery and being proud of it! :)

That wasn't the takeaway some of us read here, and honestly, that's just foolish. Take pride in your craftsmanship, never take pride in your tools. I love my hammer, but when I need a screwdriver, it's a stupid choice.

<comment><USER29> On the other hand, don't be ashamed of using a tool that works for the job, even if it isn't the latest or coolest thing. jQuery is no longer the best choice for a lot or circumstances, but if it is for yours, go for it.</comment></comment></comment>