shortstuffsushi

It shouldn't be deprecated because of my issues, no. It should be because it's not something a new project is likely to start with like I was saying. If someone was starting a new project, it's unlikely they would pick Cordova as a platform, imo or from what I've seen. PhoneGap, owned by Adobe, in particular​ is a big question mark on top of that to me.

Now, as to my specific issues, it's really the same as any other common anti-hybrid argument.

One, it's never write once run across platforms, it's write once and then debug across all platforms and insert various hacks for bits of slight inequality between all of them.

Two, plugins are native and consequently require knowledge of native to implement or, again, debug. If you're writing your own plugins, you can pretty easily get to a point where the js code is indeed write once for all platforms, but then you have to write the native portion for each still. This falls apart if you want to write more complex / device feature heavy apps. Given that may not be your use case, less complex apps are indeed easier to make cross platform. This isn't because "your project is a big mess," it's because you're trying to use features that aren't exposed to the browser js engine on the device.

Three, bugs in Cordova. As with any external dependency, you're at the whim of their quality and release cycle. Various bits of fun, "legacy" / backwards compat, and design decisions combine to lead to situations where things like the onload of the page in the cordova.js file is wrapped in a setTimeout intended to fix a problem on a platform a couple years ago in some way ends up taking your page nearly a second to display as it waits to gets it's turn on the js execution cycle again. Sure, one off example, but the one that I remember digging into. I logged a number of issues during my time, though.

Four, and perhaps most opinion based, the apps you're making almost never feel native. You spend all your time trying to make the app feel closer to what it would be if you wrote it natively, or look closer, or whatever, but you're again at the mercy of the js engine on the device. There are cases where it just can't compete, period.

So, what's so hard about Cordova for me? No one thing. Many little things. I didn't even touch the build process and what to do when that starts acting up. The amount of time I spent fighting Cordova (and to be fair, other hybrid frameworks) in my experience was as much as it would have been to write a nicer native app, and I would consequently never recommend anyone go that route for more than a trivial app.

As for "allowing developers to jump right in," well, I think you're a bit misguided. It's not more user friendly than any of the native app starters, and tbh is probably less so.

But that's all just my opinion, so keep writing whatever you enjoy.

I still haven't gotten around to trying React Native, but after being burdened for almost two years with Cordova development and maintenance, I'm at best "afraid" to go back to any hybrid solution, and more realistically openly opposed. I even tried to contribute back (to Cordova, I still don't know what the value add of Adobe's PhoneGap is beyond it), but it's just such a mess.

To see several years later now that they're still trying to push forward surprises me. I know there are many apps that were built on this platform, and are likely still in maintenance phases, but is anyone starting down that route these days? If not, maybe it's time instead for the incredible journey announcement as they shift into deprecation and closure. At least on Adobe's side, as stated above, I don't know what value they have in continuing their support. Let it live on as only an Apache product if it must go on.

Or "" ...

I don't think it's either/or. You can make a "flashy" (in the sense of Buzzfeed) without it being burdened by huge amounts of js. Likewise, monetized sites are still frequently not like Wikipedia or HN.

Probably only in their front end code.

Perhaps I'm missing the difference between your examples in HTML vs XML. Ultimately it's just another view of the same data, which could be driven all via the same request with a different Accept header. JSON, XML, and HTML would all provide identical data and the other requisite links, etc, HTML is just inherently human readable (ish, assuming browser rendering).

I've had a couple of interesting projects developed much in that manner, where a single API served both a website (browser default Accept is HTML) and mobile requested with JSON Accept. A simple middleware layer that varies the response (which is just some plain old xxx object) and returns the preferred media.

I'm not sure that I agree that with your analysis of JSON. Semantically you're correct about it not being hypertext, but I don't think that precludes it as an effective media for a REST/HATEOS application.

Don't know that you'll want to hear this, but every time I've run into returning view data from the server, I've had problems (something something separation of concerns). Unless you have both a data endpoint directly and a separate view endpoint, or a data endpoint that you can dictate to return the view, I would not recommend this approach. You're blocking yourself into a corner doing it this way.

Err... You just took this to the opposite extreme. Not recognizing that men have to face problems related to divorce doesn't mean you should throw the institution of marriage out the window as a racket.

To be honest, I'm of the opinion that they're "automagical" fixes have made things worse. Back in my day we understood what was going on behind the scenes and subsequently knew how to fix the problems, and now that these tools exist, I frequently find them to be in the way of fixing things that I would otherwise know how to do myself.

You make it sound like it is as simple as that, only a method table instead of a header field :)

That said, you mention using a varint or uint32 which "use more CPU or memory" -- 16 bits vs 32 bits in applications that use megabytes seems trivial. Can you explain why that's a concern?

Came here to say much the same. GPL / non-MIT generally = avoid, because IANAL and don't want to figure out if I'm in the right or wrong.

Really? Sure the concept is a little silly, but it'd be a neat little project to whip up.

Yes, I meant the backend. Apparently I misread the part where this is a SaaS product, I thought you could host the backend.

The one real downside here is that you're tying your users to Windows. If you had a more "pluggable" db layer, they could use the platform of their choice.

That said, the code is in C# as well (and not .NET core, from what I saw), so they're pretty tied to Windows anyway, which is awkward since this is a macOS app.

It seems Urmson is named because the two of them are the leaders of the Aurura company named in the suit.

To be fair, this seems like a decent idea for recruitment. Someone with an active iOS developer account is a good deal more likely to be a "real" developer than a random LinkedIn crawl. That's still pretty shady, though.

This makes it SUPER obvious when they're lying, for me. My profile, at the end, if you press "read more," specifically says no Amazon recruiters. None of them read it. Ever. Or if they did, they specifically overlook it and don't acknowledge it in their spam mail.

The funny thing is that I've had several smaller / more local recruiters comment on it and laugh. They get a small amount of respect / hold my attention longer than the first line of the email.

If it was less than once every two weeks, it wouldn't be such a problem. Heck, once in three months like in the article sounds like a huge improvement. They are seriously relentless.

I'm sorry you feel this way, but our market studies have shown that most of our users respond positively to being spammed daily, and almost all of them come back and spend money as a result!!!!111!

Hmm. I don't think I can get behind the idea that Trello "disrupted" Atlassian, and certainly not that it would have killed them (no more than Medium killed WordPress...). At most, it may have killed Jira, but Trello seems to capture a slightly different market. Could there be a slimmed version of Jira that could fit in place of Trello? Sure, but I don't think Atlassian would have gone that route (thus the acquisition, right?). Then, when their big product paid off, they bought the sub market as well.

Re:integration, I also think he shortchanges Atlassian. I like Atlassian, so I'm biased, sure, but I think that they could successfully integrate without "killing" Trello. Time will tell on that, I suppose. Also, to say that "Android isn't incorporated into Google" just doesn't seem right. It's also completely different. Google acquired Android, which is a mobile platform, where they're a web company. Atlassian and Trello both offer web based services, and in this case even the same type of product.

Not gonna lie, this would be a complete turnoff to me. Something something exploding offers and whatnot. If you can't spare a week for someone new to start, something is probably out of whack. If they keep pushing back, sure, but if it's a week "because I want to help out my team," are you going to hold that against them? Would you want them to bail on you like that when they leave your company?

I also hate this, but what rule does that violate? Perhaps 4.5.4?

> 4.5.4 Push Notifications must not be required for the app to function, and should not be used for advertising, promotions, or direct marketing purposes or to send sensitive personal or confidential information.

It's a should and not a must... I'm not sure if they enforce all "shoulds." Also, from a review perspective, how could you tell? These sort of notifications are typically triggered after days (or hours) of inactivity, and I don't think they observe your app that long.

If you, as a user, complained about an app doing this to Apple, I wonder if they'd pull it.

So, I have a couple of questions here -- one for UBI and one for you.

1. You're hoping for UBI so that you can quit the work force and get a PhD, so you're going to (at least temporarily) cease to input money into the system, and start to take money from the system. That seems like effectively twice the cost. Where does that money come from, if you and other people have that same idea? This is the part of UBI I'm struggling to comprehend. There's the idea that you will come out of school "more valuable," but that's speculative vs your current position which is actively adding value (albeit less than what you feel you're worth).

2. Why do you need UBI in order to do this? Are you making no money beyond the absolute minimum you need to live with your current job? Couldn't you potentially save some away and then do the "nights and weekends" sort of school that some people do? To your very last point, you mention having to hope for one of your startups goes big, but could you take a more "steady" / traditional job and make a decent amount of money that way?

Unpopular opinion: this strikes me as exactly a case against UBI. You're taking an active, and perhaps more importantly, tax-contributing member of society, and incentivizing them to stop being one. "Innovation would move quicker" is a great idea, but I don't think it's all that much of a guarantee. It seems likely to me that it would continue near the same pace. But, that's also just speculation / without citation.

I end up going almost exclusively to Crashytics' website, then being redirected at login and have the "oh, right" moment.

I've logged a number of tickets against their product, their solution seems most frequently to be "we're merging this with another ticket that's about 50% related, fixing some other issue, then closing this ticket and opening another one for other issues since merged into this ticket, elsewhere." If you follow the ticket trail around long enough, you may see your issue fixed, but I haven't been that dedicated yet. Their support process is certainly pretty crappy.

They did merge it with Stash, though, didn't they?

What about HipChat don't you like? I know it can be buggy at times, but from a strictly functional perspective, I feel like it's ok, or at least sufficient for me.

Or from any "smart" editor like Outlook.

I may have asked this here before, or perhaps elsewhere... but why do these characters exist? "Smart" quotes end up breaking things for me so frequently, I've never actually wanted them in any case I can think of. Same goes for en/em dashes. I literally spent a day and a half trying to track down an issue less than a month ago, only to realize as I got to the point of inspecting bytes that I wasn't looking at a regular dash (and incidentally that the SDK I was interacting with doesn't support extended characters).

I'd be willing to bet the 100 person start up you're part of is largely of a different demographic than the parent's DNC staff group.