jamesbrady

> it is understood that everyone has their eye open for the next big opportunity

This hasn't been my approach, nor has it been for many people I've worked with – or perhaps we're tripping over language?

Let's say that someone is super motivated by a high salary. They would be helping their manager (and, in most situations, themselves) if they were open about that. Up to and including conversations like "I hear that Company X is paying 20% more for a comparable role – here's some data to show I'm underpaid".

It's those kinds of conversations which would mean that your manager won't be surprised if in 6 months you leave for a better-paying role. Or, perhaps you get a nice pay rise. Or, if you can't have such conversations, see the red "you should leave anyway" box in the post!

Your first sentence is true. Perhaps it's overly reductive of me, but if that's what your boss would do you're in that red "you should leave anyway" box, in my opinion.

A few other commenters have pointed out good reasons (e.g. visas) where you need to keep your cards closer to your chest, but the vast majority of people reading Hacker News can find a role where it's not so transactional. Where you're valued as a person and teammate, and where you can have a grown-up conversation about your career plans.

Those open conversations are harder to have if you truly believe your second sentence, however!

I think it depends on the situation. I definitely agree that performance-based firings would tend to be extremely brutal compared to the approach I advocate for here (largely due to the various risks posed by aggrieved employees).

Perhaps I should add that this advice best (only?) applies if you're leaving a company in a sort of "natural parting of ways" kind of situation? Thanks for the feedback.

Oh, I hadn't considered role-tied visas… that's a good point. Let me add a couple of "excepts" in there. "Never" is too absolute.

Exactly, this sounds like such a grown-up way to wind down a working relationship! I'm sure you'll stay in touch with that person and perhaps even refer people in their direction in the future.

Hmm, I hear you on the first point… Perhaps I'm blinkered to roles in tech (to which this post was aimed, but not explicitly enough)?

In my experience at such companies, people certainly aren't walked if they express dissatisfaction in their role – but you're right that this doesn't necessarily transfer onto roles which are less competitive. I will think about how to tighten that piece up: thanks for the feedback.

On the second point, I can only congratulate you if you manage to keep everything so organised and compartmentalised! It's something I've aspired to but always fallen short of.

I'm sorry that's been your experience!

These managers definitely do exist - I have had them, I have seen them, and I have tried to be one.

Perhaps I should have included "rational conversation is possible" as a decision point in the flowchart, with a negative answer leading to "you should leave anyway"!

This is already happening: the top 5 virtual influencers have over 11MM followers in total.

It's not clear this is healthier.

Make part of your AI DJ a reinforcement learning agent whose reward function considers the amplitude and coherence of the movement of the crowd.

This agent would enjoy the moving crowds in a much more authentic way than a human DJ would.

I can't find it now, but there was a wearable project (I believe earrings?) which gave quantitative feedback about how a music audience were moving.

I don't think we need "objectively best" here—merely "subjectively best". And because each person could have their own AI DJ trained on an arbitrarily rich set of preferences and experiences from their one-person audience, we should expect that AI DJ to be subjectively the best for their respective human.

Obviously, this overlooks the shared experience element of music, but that's not so relevant in the case of online music we consume solo.

We actually do support native plugins - alpha live now, beta coming soon: http://docs.trigger.io/en/v1.4/modules/native/index.html

You mean PhoneGap Build? It's actually a bit different, because you have to send up your whole app to their server, where a compile and package is done and the fully-baked app is returned.

Useful in some situations, to be sure, but this approach means you still get all the benefits of the Trigger toolchain - builds are done in seconds rather than minutes.

Hi Matt,

Of course, there were a number of reasons we were wary of being downstream of PhoneGap. The specific issue of Android performance wasn't a blocker, but was, to us, symptomatic of a philosophical difference between PhoneGap's approach and ours. We're not saying one is Right and one is Wrong - we just have different priorities.

Another key aspect for us was that our runtime platform is tightly integrated with our tooling: how those tools interact with the generation of runnable apps is obviously key to usability of our product, so we were very uncomfortable not owning such a key part of the puzzle.

The other option would have been to fork PhoneGap with no intention to push upstream, but that, to me, is against the spirit of open source, and still not optimal to us as we'd need to shoe-horn our tooling to fit a code base not designed with our needs in mind.

Hi, Agreed that in your standard app, the overhead of rendering will outweigh that of communication with native code.

For us at Trigger, however, we don't have any control over the efficiency of your Javascript, or the interpreter and rendering engine that holds it.

What we can control is how efficient the communication is between your JS and the underlying native APIs. Everyone agrees that performance is a key issue, so we take great care to ensure that the performance of code we control is as small as possible.

Yep, I was referring more to native accelerometer events being fed into the web view.

True enough that on iOS we would perform comparably, but for Android, it would mean "long"-polling a local web server at 60Hz!

Thanks for the link - I can only see two mentions of 2.2 in that thread: one (in the first question) where the OP was asking about it, and another mention from Patrick, suggesting he think the issue only affects 2.3 phone using JSC. We don't know of any shipped phones that fall into that category.

Remember, this post was called "Why Trigger.io doesn’t use PhoneGap" - it's about the reasons we chose not to live downstream from you, not just a post bashing what you've done.

For us, the significant delta in performance is evidence of a different philosophy between what we are aiming for, and what you offer. We clearly want to make different design decisions, and need to be independent to do that properly.

Hey Patrick, we support from v2.0 upwards, although not as heavily tested on 2.0 and 2.1. Our tooling actually sets users up with an AVD, and our docs (http://docs.trigger.io/en/v1.2/android/getting-started.html) do say that 2.3 is not supported on the emulator.

Although we obviously can't test every device out there, everything so far points at no device ever actually shipping with JSC after 2.2, e.g. see http://code.google.com/p/android/issues/detail?id=12987

If we do get requests from our users to change that approach, we'd obviously consider it, but at the moment, we think the significant performance and code cleanliness benefits outweigh the downside.

Hey Andrew - a disclaimer of my own: I'm a co-founder of Trigger.

Actually, we think this is a pretty important benchmark: battery drain and general responsiveness is a huge deal on mobile devices, so we take performance of the bridge very seriously. Every millisecond counts here.

Also, I can absolutely see the need to send large number of messages - a streaming accelerometer API, for example, which is on our roadmap.

You're right that there might be trade-offs between raw performance and supporting every quirk of every device. However, in this case, the Android bug you refer to only affects v2.3 emulators, not actual devices (to the best of our knowledge). We automatically set up our users with a v2.2 emulator to side step the problem.

We think such significant performance gains for our users, and a much cleaner, easier to maintain codebase for us, is well worth it in this case.

Thanks! Yep, we see good command-line tools as being the best substrate to build on: even if we did support every platform, people are going to want to run scheduled builds and so on.

We actually find ourselves developing as Chrome extensions for the first few iterations, purely because the debugging tools there are great. After that, it's an easy switch into a mobile app, using our Catalyst debugging tool.

Architecturally, we're more similar to PhoneGap than Appcelerator: we do use the native WebView as a container for the app.

There's a million things to talk about and this margin is too narrow: I might do a deeper dive in a follow-up post...

What version of IE? Looks OK for me on IE9 (and IE7/8 mode)...

Can you get to our main site https://trigger.io/ ?

Some changes you make to your app configuration can affect what we need to do in the native code, so when that happens we have to go and do a rebuild on our servers.

When you're hacking away on your own code - JavaScript, HTML and CSS - no re-compilation is required and you can have a new app up and running on your device in a matter of seconds.

We think speeding up that development cycle is one of the keys things we need to deliver on to keep our customers happy.

Thanks Andy - yep, we're constantly balancing two desires: the desire to expose every last shiny detail of the native platform on one hand, and the desire for consistency across platforms on the other.

The list of amazing, engaging, good-looking apps implemented in HTML5 is long, and growing. Personally, I think performance was the biggest hurdle in the race to make HTML5 look "as good as native", and rendering and JS execution speed is incredible now - and getting even better!

Interesting... what sort of thing are you thinking of: the ability to easily manage subscriptions from within an app, or view content, all of the above?

Awesome, sounds like a great match: Sign up and give us a try!

Most of us develop on Linux, so our support there is pretty mature.

PhoneGap's a good product, and definitely has its place. However, we've heard from lots of people (some of whom we now value as customers) that for apps which don't need bespoke native functionality it can be too heavy-weight: this affects everything from tooling to build process to bloat in the platform itself.

Some of the main tangible benefits we offer over our competition, and PhoneGap in particular:

* much faster build process (apps re-generated across 6 platforms in < 1s in the main-line case)

* unlimited support, and help prototyping your app at higher tiers: Nitobi is/was basically a consultancy based on PhoneGap whereas we see ourselves as building and licensing a software platform

* guarantee we'll never be bought by Adobe and get rolled up into Dreamweaver (not a guarantee)

* make no requirements on the IDE or other tools you use - you're good to go with a terminal and a text editor

In general, we try to be light-weight, get out of the way as much as possible, and offer a great, streamlined experience for users writing apps in the bottom 50% of the complexity spectrum.

Disclaimer: you might have guessed I work for Trigger :)

That's interesting, I stand corrected - it is interesting how the trend has cycled between centralised and distributed compute resources over the decades, and IBM's been on the ride the whole time.

btw, when are you leaving Hursley ? ;-)

Yes, of all of those guys, I think Microsoft are most likely next to act, as it would also be the perfect opportunity for them to offer any cloud-based Office products they may or may not be developing :)

Great question, I might well write another post about this because it's a really interesting problem.

The software and services that we looked at to address this problem all left us pretty lukewarm. We needed distributed configuration and resource management, logging and alerting at a minimum.

To cut a long story short, we've written our own system, which draws on ideas from things like rush, capistrano, munin and nagios and tailors it for our needs.

At the moment, we have a system which gives us the information we need to make decisions on commissioning new servers etc, and wakes us up in the middle of the night when something goes wrong. I expect the capabilities to grow to include auto-scaling, auto-healing and some other bits and pieces as I get the time and our needs mature.

My view is that you probably won't see the HP/IBM/... companies enter this market as it's already commoditised (even though there's only really one player): they prefer to focus on high value, high margin products and services.

Sun is the only one in the space: http://www.sun.com/service/sungrid/index.jsp - they're currently task-centric grid computing rather than machine-centric cloud computing.

In many ways, running applications on a grid rather than machines in a cloud is a more pleasing idea, and fits better with the point I make in the post, but pragmatism wins out: the edge cases and dynamic requirements mean running virtual machines is often much more convenient.