Nemcue

Do you think you're allowed to talk about the government suppressing you?

And the point isn't that they weren't able to suppress crypto code; it's that they tried.

Maybe not for you, but there's plenty of applications where ease-of-use and threaded conversations are a very big deal.

For a very good reason, mind you. IRC isn't for normal people. Nor does it support threaded conversations.

"We've had weapons that choose to kill on their own since the landmine."

You're right. That's why most of us have signed the https://en.wikipedia.org/wiki/Ottawa_Treaty and multiple treaties just like it.

This is not good advice.

What about a function that you want to pass around and have other actors give it arguments until it executes?

Can't really do that with .bind without executing it.

"I really wish the Chrome remote debugger allowed multiple websocket connections."

You, me, and a ton of other people. It's the number 1 starred Dev-Tools issue[1], and has been for years now. I'm guessing it's a political issue since there has been no indication whatsoever towards providing a solution.

It really is a big deal; there's a ton of potential applications if we could plug multiple things into a single page.

I think spy.js only scratches the surface of what's possible in this space; and spy.js is pretty awesome (if only it wasn't dreadfully slow and tied to an IDE).

[1] https://code.google.com/p/chromium/issues/detail?id=129539

Except it is at the expense of people, so that's not true at all.

SRS are notorious for brigading and messing with peoples lives.

You say this with certainty? Do you know this to be true?

Because I seriously doubt it.

> again there is nothing special about writing a web-based front-end really.

I thoroughly disagree. There are a lot of challenges and opportunities with web apps that you do not have in the same way in other UI environments. Having a way of enumerating different states of the application, and jumping between those states (URIs) is just one.

Sure you can be productive as a single developer. The problem is when you're handed a project from another single developer-project, and the project is a hot mess of spaghetti jQuery where business logic is intertwined with DOM manipulation. It's basically impossible to work with unless you've created the code yourself.

"But aren’t tools the problem?"

No, they aren't.

This entire article read like it was written by someone that has never in their life been involved in the development of a website / app.

"It was also fascinating how Jodorowsky never actually read Dune."

It's so bizarre how people keep saying this, because you're far from being the first; like you all fell asleep during the exact same segment.

He _did_ read the book. He clearly says so in the documentary.

He hadn't read the book before he got the go-ahead from the producer.

Not really. Despite tools you'd still want someone to act like an intermediate with the one doing the AMA.

This is about poor communication, and how Reddit treats the ones that actually make it all go around.

> lot of libraries won't work with python 3 which is why 2.7 still matters

A lot of libraries actually work with python 3. And most of them that don't have a python 3 version in the pipe.

http://py3readiness.org/

Ember is ~75k gzipped, so that comparison is moot.

At least intuitively one doesn't think it would cost half a million dollars for a year.

As if suits ever wanted anything else but new sexy features.

It's a fun experience trying to introduce command lines to people who have lived in IDE-land all their lives.

"Command Line?! HAHAHAH"

Try making a playlist on the iPhone app with 15 songs. Maybe you mistakenly added two songs — try deleting those.

Just try it. You'll understand.

I could also just download all my music and use any music player that I want — point is I don't want to spend a lot of time maintaining a music library nor do I want to write my own god damn player.

I just want to fix the details about the Spotify client that I don't like. It's all js/css so why the fuck can't I? I can do anything I want with Atom, why not Spotify?

Meanwhile at Spotify HQ:

"OK guys — it's been more than a couple of months since we scrapped features that people like. Let's spin the wheel of misfortune, shall we?"

"Maybe we should hold more talks about how awesome our processes are, and how agile we've become — all the while letting our core product languish and not listen to our customers needs."

"Hey, could you take a look at this? I've spent all weekend creating a better version of the playlist-view. It uses twice the amount of padding from before. Maybe this encourages more in-depth listening, since you have to scroll a lot more. What do you think? It's nice, right? Perhaps we should also require the users to click and drag the scrollbar?"

(I love Spotify though. I just wish they put a little more effort into their applications — or at least made it customisable so I could make semi-permanent fixes myself. The only meaningful feature they have shipped that has impacted me the last two years is detection of duplicates in a playlist. Like seriously, what are you guys doing?)

"Spotify and SoundCloud are some of the European IT stories at the moment, if they are both slaughtered by Apple, that will not go well for trade negotiations."

Oh please, like anyone doing trade negotiations would give a shit. Do you think those people have even heard about soundcloud? They haven't.

You didn't provide a link. I assume you were going to link the blog post announcing their switch to Mithril — that didn't contain any rationale behind it.

I did find this however, which goes into details about why Ember was not a good choice for them: http://discuss.flarum.org/139-introducing-flarum-s-fast-new-...

Seems to be a well based choice. Doesn't seem to have anything to do with performance though.

While Mithril is probably a lot more extensible and easeier to work with since there's a smaller API surface, seeing "templates" like this makes me sad:

  view() {
    return m('div.text-editor', {config: this.element}, [
      m('textarea.form-control.flexible-height', {
        config: this.configTextarea.bind(this),
        oninput: m.withAttr('value', this.oninput.bind(this)),
        placeholder: this.props.placeholder || '',
        disabled: !!this.props.disabled,
        value: this.value()
      }),
      m('ul.text-editor-controls', listItems(this.controlItems().  toArray()))  
    ]);
  }

> React with Backbone feels it could have been an equally good (if not better) choice.

Superficially it might "feel" like a better choice, but objectively it would have been worse if you're doing anything non-trivial.

The backbone router is severely lacking compared to the Ember Router. Same thing with having a lot of models with relationships between them. Sure there might be Backbone-related projects that try to tackle it — they are all way worse than the Ember equivalents. In my opinion they either lack tests, functionality or have terrible architecture.

I think it's a huge merit of the Ember community that they're moving in this direction. They saw something that worked better and weren't ashamed to say "Well that's better than what we have. We're going to do that instead".

Going by track-record and where they are today, Ember would in my mind be a great choice for any company that wants to start building web applications. Ember-CLI is a huge productivity boost, and I bet any company doing more than a few SPAs has had to build something similar; and it probably ended up way worse than Ember CLI.

I find it very unfortunate that web developers have all put their eggs in the Angular basket. From my point of view the rationale for choosing Angular today seem to be the network effect of readily available developers, and not so much the merits of the framework itself.

The Angular team realised they could do things better, and rewrote their entire framework. The Ember team realised they could do things better, and is incrementally moving towards that while letting you migrate your app with it.

tldr; How you use the computer / manage application windows is more important than multiple screens for productivity. If the way you interact with windows and applications isn't cerebral then you're doing it wrong.

First of all, I'd say his argument is perhaps less applicable if you're a programmer. If all you're using a word processor and a browser, then maybe you can get by. If you're doing programming and designing, and need a couple of applications as well as a few terminal windows — then maybe it's not so applicable.

However, I do find this subject matter really interesting. I've been thinking and observing about this a lot just this last year, and I think it's not so much about screens as it is how poorly most people use computers.

I think the main productivity killer is the cursor and how people do window management: focusing an app, resizing, moving, shifting screens and so on.

As an example, say you as a professional need to use three applications, and most of the time you use these applications in a maximized state — taking up most of the screen space.

Now, if you want to shift attention between these applications, there are a couple of alternatives. You could alt-tab, which is imprecise and slow, since you have to mentally go through the alt-tab stack of applications and find the one you're looking for. Of course, you can use alt-tab to toggle between two specific windows, but if you slip up and press it twice then you bring focus to some other application. It's just not really a good way of switching windows.

Another way is of course to use some graphical element targeting a specific application. Maybe the bottom menu (the dock on OSX). This is also imprecise and tedious. Windows tries to fix this with having the order of the applications correlate to shortcuts. So the first one can be activated using Windows Key + 1, the second one with Windows Key + 2 etc. This still leaves you with the problem however that you lose state between toggling applications since your cursor isn't where you left it for that particular application. There's also not a good way of toggling between windows for an application: say you have two chrome windows, and you want to switch between them.

Or maybe you have multiple screens, and you now have to drag the cursor between the windows. Super slow and imprecise, and maybe the cursor even gets caught between the screens since one of them is in portrait mode and the other is in landscape — now you have to spend even more mental effort just to get it to where you want to go.

The way I've solved these issues — which has given me a huge productivity boost with a laptop in particular but it's also very tangible on desktop computers with multiple screens as well — is to create a really smart system to jump between applications where it remembers where the cursor was for that particular window, and if the cursor is in some nonsensical place when you jump to an application window then it's instead reset by centering on that particular window. It also uses a graphical element surrounding the cursor which shows for about half a second, so I don't have to spend any mental effort to find it. I also have a very nice system to manipulate windows which sort of works like Divvy where using the keyboard I can on the fly define a grid on the screen, and move or resize the focused window inside of that grid.

Using things like this makes it cerebral. I don't have to think, or spend mental effort targeting things. It's all super precise and I don't even think about windows and screens most of the time, it's all mechanics that have become invisible to me when I work.

I'd bet with this setup I'd be a lot more productive with one screen than someone with two screens without a similar setup.

Yes! You're so right.

I've actually experienced this first hand. There's a small but prolific community on OSX who do this for Window Management and Automation; see https://github.com/jasonm23/phoenix and http://hammerspoon.org

They're great to work with, and it's easy to build your own abstractions on top since they actually have a real language that you can work with. Imagine this for instance:

  Windows.find(window => window.title == "Sublime Text")
         .moveTo(Screen.find(screen => screen.name.contains("Dell"))

It's so bizarre to me this isn't a thing in Windows. It's a super good thing to have.

Ugh — this plague again. No other coding community has latched on to performance tests like the javascript one. For NO GOOD REASON.

They're not expensive. You're not binding thousands of times a second anyway, so stop your silly premature optimizations.

Gah. I thought this was a library to do Automation in Windows using Javascript. That would have been a dream compared to what the Windows ecosystem currently has.

Autohotkey et.al are impressive in terms of functionality, but holy hell is the syntax and structure awful.

models aren't hard problems?

OK, then show me a js model system that does one-to-one, one-to-many, and many-to-many relationships — while still having clear, concise and understandable code.