PhoneGap vs. Native: Some Thoughts on Going Native - <AUTHOR> https://groups.google.com/forum/#!topic/phonegap/BFyBYjQp3a8

<comment><USER2> I spent an inordinate amount of time fighting webkit before switching all of our stuff to native. The four biggest problems, I think, with the state of webkit are:

1) Implicit memory management of large images/surfaces isn't reliable. There's basically nothing you can do (outside of not doing anything) to prevent your page from crashing webkit if you use too many (where too many is undefined) accelerated elements/total texture space. There's no "Running low on memory" callbacks or means to explicitly remove a recently drawn image from memory outside of removing it from the DOM and crossing your fingers.

2) Lack of proper prioritization in javascript. One of the things that IOS focuses on a lot is separating out user interaction on the main thread from everything else on background threads. In JS, if you're not careful and you do an innerHTML in the wrong spot, you can lock up a bunch of user interaction or delay an AJAX request that would otherwise be executing. Maybe the answer here is something like .updateInnerHTMLWithCallback(function foo(){}) to prevent breakage of JS that does expect the DOM to be consistent after an innerHTML update. (Edit: Oh I forgot, we actually did something similar to this by doing all of our innerHTML updates in setTimeout'ed functions with a 1ms delay). There's a lot of weird stuff around loading images and keeping UI responsiveness then as well.

3) No cache beyond pure source code between separate user sessions. One of the biggest issues for us was initial load time (parsing and calculating CSS, parsing and running JS, and blitting down accelerated DOM elements, etc). Once everything was loaded we could imitate a native-level experience, but this often would be 10-15 seconds in. Perhaps an intermediate cached file (kind of like python's pyc) would help alleviate this.

4) Debugging. This was covered, but ugh, what a nightmare. At a certain point I was booting up XCode instruments and tracing through webkit code to figure out what parts of our JS/CSS/etc to optimize.

<comment><USER3> I'm not a mobile webdev, but about (2), did you try using Webworkers for the background tasks? iOS Safari supports it nowadays, right?

<comment><USER4> Web workers doesn't really work. Somehow, It still blocks the main UI thread.

<comment><USER5> That's a bummer. I was planning to rely on them soon.

Any links to more detail?

</comment></comment></comment></comment><comment><USER6> I am equally productive with web as well as native development so it makes no difference to me. Not surprisingly, Phonegap never appealed much - same work, inferior results, single (but dubious) benefit: cross platform.

I was pleasantly surprised by Titanium mobile though when I had to evaluate it at my job 2 years ago. I set to reimplement one of our (non-trivial) apps and summarize my experience. I ended up writing 50% less code and it took about the same time as what I had spent on the native version. I consider this a compliment though as I was completely new to Titanium. On the flip side I was completely new to the app when I wrote it the first time :-)

The build/run/debug loop was unpleasant but I've heard that it has improved since then. As for performance, it was good - Titanium generates native UI, albeit with an interpreter in the middle.

I was quite surprised when it turned out that I have a 99% identical app. You see, from the very beginning I decided that I'll be hard on Titanium, my goal was no-compromise, high-fidelity clone. And it worked. The only problem was positioning a tooltip near a touch point - at the time there was no way to traverse the view hierarchy. But then again, maybe I could have implemented it in a different way.

I realize a lot has changed since than, but this is my 2 cents - sharing a real world/product experience.

<comment><USER7> Titanium has come a long well, I eval'd it around 18months ago and was frustrated with 'how the heck do I build something that doesn't leak'. I was amazed at how quick I got something running, until it crashed... I hugely struggled with the best way to build an app.

12 months later, the SDK has improved, and documentation has improved. I circled round to Titanium again. Now I've got an app in my spare time that's pretty close to store submission, not leaking, not crashing, all native. I'd find it very hard to go past Titanium now. Once you get into a groove with the CommonJS style ([https://wiki.appcelerator.org/display/guides/CommonJS+Module...](https://wiki.appcelerator.org/display/guides/CommonJS+Modules+in+Titanium)) of constructing your app, and follow some of the latest examples, it all clicks into place.

I haven't tried to learn Objective-c (Rails/Javascript guy) however if you're not building a game, or trying to get 10/10ths out of a native app, I think it's damn good solution.

<comment><USER8> I disagree with the "if you're building a game" part. I build games in JavaScript/HTML5 for iPhone/Android, package them to apps using appMobi and it works pretty good. I haven't tried PhoneGap though but I guess it's more or less the same thing.

<comment><USER7> Sorry I should preface it with 'if you're building a game to squeeze all resources out of a system'. As obviously there is a (pretty small) overhead with running the interpreter..

</comment></comment></comment></comment><comment><USER9> This person successfully managed to trade a bunch of irritating issues for a different set of irritating issues: that generally makes one feel happier, as working around new and thereby relatively exciting irritating issues as a vacation from the worn and tired ones we are now so sick of it makes us want to die, is all many of us can hope for in life.

<comment> Arcanum-XIII It's not exactly like that — there will always be issue, we know it, but some are more irritating than other. I can handle Xcode crashing, and needing some help to compile everything — I can live with that. The debugging part otherwise, is subpar. It's (at least for me), a true hell. Appcelerator was the king of unusable error for example, that and a lack of GOOD (heck, even complete) doc were driving me mad.

So yes he has made a trade. I think a good one, but to each his own !

<comment><USER9> Context: I have been doing iOS app development, both native and with massive amounts of mixed in HTML (using a home-grown mechanism similar to, though I will personally claim nearly infinitely better than, PhoneGap) since early 2008 (yes: half a year before the SDK existed).

The day you realize that what version of Xcode you were using when you compiled the application (in addition to the version of the firmware installed on the device) affects the behavior of UI classes on deployed units, and that these effects are not documented (and are in some cases /insane/) is the day you realize that no: it is just different.

To describe this another way: yes... Apple seriously implemented a kind of "quirks mode" (I believe that is the most fair, accurate, and descriptive term to use to describe it, by analogy to web browsers) in the UIKit framework on the device; they will change the behavior of the library slightly, and then do runtime checks to determine "could you have known that we did that".

To be clear: this is not due to compiler bugs; they do it with a runtime function called UIApplicationLinkedOnOrAfter() (to be clear: which looks at the date of the UIKit library used, not the date of the link). I discovered this after spending an incomprehensible amount of time attempting to debug a serious UI issue that only occurred when /some/ of the developers working on my project compiled it: I sat around disassembling and tracing and then... "woah".

The places where I have seen this stuff used, while attempting to maintain an application not over the course of a few months but over the course of now over four years, has been sufficiently "wtf" that on iOS 4.1 I finally wrote a tool that disassembled UIKit, found all of the calls to that function, and attempted to document "for what version it is being compared".

(I intended to at some point even write a detailed blog post about this, with examples, and a chart of all of the usages, but I've never had time. I really wish I had more time to sit around writing blog posts, but the really good ones of those take days to put together, if not even longer ;P.)

In contrast, the stupid WebKit bugs in or changes to iframes and multi-touch that seem to get traded around in every version of iOS are actually tame in comparison: they simply have not caused the kind of debugging hell and frustration that the simpler native components have caused. I have only once been "I upgraded to the latest version of iOS and all of my content disappeared" with HTML (iframes with height=0 stopped auto-sizing: changed to height=1: irritating as now an iframe cannot autosize so small as to disappear), but it has happened four or five times with my native code.

So there: just another set of anecdote to throw in the pile of "irritating garbage" and "debugging hell" that people like to throw around about everything they do. Personally, I find that I'm happiest when I switch back/forth between doing Objective-C, HTML, Python (server), and assembly (reversing) a lot, so that no specific one set of irritating problems ever becomes so depressing that I throw up my arms and quit (which has totally happened a few times).

</comment></comment></comment><comment><USER10> These types of apps sit solidly in an uncanny valley of application design. They appear as if they should work like a native app, and they pretty much do, but not quite. The fact that they look like a native app greatly magnifies that last missing 10%.

Unfortunately, this isn't just a mobile problem, as web apps get more interactive, we're hitting this problem on the wider web as well.

</comment><comment><USER11> I like this post. I'd like it if we could get studies/posts on:

1) A/B testing of users' responses and revenue outcomes on native vs wrapper implementations of apps

2) Webkit performance metrics in wrapped apps on different platforms (e.g., exactly how slow is the app on the 4S, why, and can this be mitigated?)

3) good approaches to interfaces that don't confuse or put off the user but are simple enough to run smoothly in Webkit

I'd love it if anyone could point me to enlightening information on these topics.

<comment><USER12> For A/B testing:

I'm working on a fast testing framework for native iOS apps. I posted some early design specs at appgrok.com. There's also clutch.io, which supports iOS app iterations (things similar to A/B testing) using a hybrid approach, if I understand it correctly.

</comment></comment><comment><USER13> Same experience with phonegap + sencha touch. My personnal conclusion is that : if you're doing "business" app (aka : where data matters much more than UI responsiveness) AND you want to release the app both for Android and iOS : go Phonegap.

Otherwise, and until the majority of smartphone become as powerful as the iphone4S, stay native. With ARC, developping on iOS with Obj C has become pretty much like developping with any other language (if not better).

<comment><USER11> What if you've already developed a (simple) Android app for consumers, and you want to enter the iOS sphere as well, but you don't have an iOS dev on the (completely bootstrapped) team? Would it be worth investing one team member's time to learn iOS development, or outsource the creation and simultaneously learn to maintain/extend the code, or to simply go with PhoneGap despite the performance drawbacks?

It's not a question that can be answered without additional context, but thoughts on various approaches for this situation would be helpful and appreciated.

<comment><USER14> In my experience it is worthwhile to learn native iOS development. Once you setup the environment and get used to XCode it is kind of fun and it doesn't take too much time. Knowledge of Android and iOS and optionally PhoneGap development will make you (or your team member) a better developer regardless of which technology you actually use. And based on that you will also be able to make an informed decision about which approach to use for a particular project.

</comment></comment></comment><comment><USER15> Funny how that exactly mirrors my experiences building a HTML5/JS app on iPad - I've quickly managed to get 90% of the app done and then wasted hours and frustrating hours of hunting WebKit performance issues, bugs without pretty much any help from tools or operating system.

Especially annoying are intermittent bugs that show only in certain minor iOS versions, which are hard to look for and test because of Apple no-downgrade policy on devices :\

Choosing native app was just a better way to keep my sanity.

</comment><comment><USER16> Great post. Having dabbled in mobile dev (and spent lots of time in web development), I always want to leverage my existing skills rather than learn new languages/dev techniques if possible. Still, a hammer - no matter how useful - is not always the right tool for the job...

For all of the attention to user interface design, I find iPhone development one of the least intuitive environments going. Objective C isn't bad, but wiring up GUIs ends up being a headache. It seems to make sense if you understand what is going on behind the scenes and look at it from the perspective of dragging / dropping / connecting widgets rather than taking corresponding steps by writing code, but I have not been working with XCode for years and don't see it that way. Most other visual development environment that I has felt somehow more intuitive (some VB, other small third party UI design tools).

<comment><USER17> In that case, skip IB and build your views in code.

<comment><USER16> Yeah, that route could work... but it is a bigger investment in time to learn another language/development environment in greater depth. At least part of the appeal for PhoneGap and other third party tools is that devs are trying to avoid XCode / Objective C development. There is something painful/time consuming about the process in comparison to other comparable programming tasks.

It seems like there are two ways of approaching GUI/language development:

1) Apples way: Keep building on a base language (C). Add new features (Object orientation, XML rather than proprietary configuration, Code Generators). Maintain backwards compatibility (your old devs will be wowed by each new release's automations and syntax improvements. New devs that have not been part of your programming tradition will require greater up front study time to grok the process).

2) Microsoft's approach: Make visual development "primary" (closer to the way one uses a GUI rather than builds it). Ignore underlying language constructs and best practices (e.g. make everything global).

Having worked with Microsoft, I thought that Apple (especially with their attention to UI design) would give developers a more intuitive interface. Perhaps it is intuitive to those who can build GUIs in code, but it was not to me. This is in stark contrast to Microsoft, where someone who knows very little about programming can create a usable GUI (and get themselves in trouble quickly as well). Don't get me wrong, I am not a Microsoft fan and spend little time in that world. However, I was able to jump in on several projects and be productive with very little ramp up time. Apple development required a greater investment of time and energy up front to be productive. Enough that I have considered PhoneGap and other tools as alternatives for subsequent development.

</comment></comment></comment><comment><USER18> My suspicion, not first-hand in this case, is not that Webkit is buggy but that it's a web browser. Browsers are not designed for embedding into applications. They are designed for wrangling a wild west of code, downloaded from untrustable origin, involving at least 3 languages (HTML, CSS, JS), and parsed at runtime.

It just a different use case than what PhoneGap is trying to do.

I don't think it's the wrong thing, I am quite attracted to it honestly. But we might be better off thinking of browsers as "web content displayers" than "runtime-programmable application plugin".

</comment><comment><USER19> We're going through the same thing right now. Built up a mobile app based on HTML/JS/CSS and bundled it inside PhoneGap and got close to done really quick... but it just doesn't feel right. So PhoneGap will be more of a StopGap until we can put more resources into a native app.

</comment><comment><USER20> It's important to distinguish between PhoneGap's performance, and the performance of jQuery mobile or Sencha Touch, which are more responsible for the native sliding and scroll features of the non-native apps.

In my experience with PhoneGap, the framework does a great job of exposing native features of the iPhone, i.e. recording audio, taking pictures. The downside for me came only came when adding the visual effects to mimic a native iPhone app. Trying to fix all of the quirks with jQuery mobile, such as persistent headers and footers (although the latest RC has been looking much better), has ultimately led to my abandonment of the non-native app.

</comment><comment><USER21> Your limits are defined by the memory size of Mobile Safari (embedded). Have you ever opened 10 tabs to see what would happen on actual apps? Now imagine full fledged JS hungry apps. Last year I warned a firm about this. Client insisted. Result - 90% was complete and the client hated the result (responsiveness & a literal boot time).

</comment><comment><USER22> The strength of PhoneGap & Co is the ease of rapid prototype-production cycling and the flexibility in UI construction empowered by CSS3/HTML5. This guy clearly took it as "a way to avoid native framework".

Interesting how one can make the right choice without of knowing what he truly wants and/or the right tool for his intent.

</comment><comment><USER23> Would it be worth doing a poll on what technologies people are using for mobile development? I've done some native Android/iPhone and now I'm jumping into HTML5. From most of the comments, I'm wondering if it's worth it.

</comment><comment><USER24> It is important to note that the author worked on a iOS only app. If he was working on one, his devision would most porbably have been the opposite, or at least more nuanced.

Still, I think he made the right decision.

</comment><comment><USER25> Another point: You have to pay to have you app reviewed on the AppStore, and it may be refused. If it is accepted, Apple will take 30% of your incomes. And your app will remain slow if it is connected to a database online.

<comment><USER26> What about the exposure it gives you app, and (potentially) _much_ more sales (it has hundreds of millions of users with credit card, and buying stuff is just one click)?

<comment><USER25> Zero exposure when your app is removed from the store (look at the news). Beside that, I am not a fan of Apple the patent troll and very reluctant to build an app specifically to them. HTML 5 has great exposure on EVERY computer.

<comment><USER26> I'm an Apple _fan_ on the whole, but like many others completely dislike many of their behaviors, including _random_ rules on the App Store.

But, App Store is a very good thing for developers. You can make a Chess game both with ObjC and HTML5, but chances of someone finding your HTML5 app via Google (search) is practically zero. On the other hand, because there are less than 150 Chess games for iPhone, if a random surfer searches the App Store for 'chess', they see your icon down the list. That's the exposure I'm talking about.

And again, I don't like Apple's rules very much, I'm just stating that being on the App Store brings you a lot of exposure.</comment></comment></comment></comment>


Coalition Announces New 'Do Not Track' Standard for Web Browsing (2015) - <AUTHOR> https://www.eff.org/press/releases/coalition-announces-new-do-not-track-standard-web-browsing <comment><USER2> The decision of the Internet advertising industry to ignore the original Do Not Track setting is a landmark in the cynicism of the industry. I mean users made an explicit request to not be tracked and companies like Google and Facebook were all "lol, no, we'll track you anyway". It's one of the reasons I feel no remorse running an ad blocker.

<comment><USER3> In fairness, a leading cause of DNT's failure is that Microsoft, for marketing purposes, chose to set DNT by default for a while. While I applaud the goal of assuming people don't want tracking, it gave ad companies an excuse to dismiss DNT: Because many users showing DNT settings had not explicitly meant to do so.

<comment><USER4> > Microsoft, for marketing purposes

If Microsoft does something in the interest of their users it is suddenly "for marketing purposes"?

> While I applaud the goal of assuming people don't want tracking

 _Of course_ people don't want tracking. I'm not going to argue everyone agrees with GDPR, but that sets the trend further.

> Because many users showing DNT settings had not explicitly meant to do so.

Just because someone doesn't explicitly agree with something, doesn't mean they disagree with that.

<comment><USER5> Even though it might in theory have been the best default for end-users, in practice they made DNT fail as a result because advertisers wanted users to make an explicit choice instead of getting opted out by default. It's easy to blame the advertisers here, and sure.. you can argue that in this scenario they were the 'more evil' ones, but had Microsoft not made this choice, we ultimately could have ended up with a respected DNT header, which later on could have become a default anyway.

So I don't disagree that the decision might have come from a good place, but the end-result was not hard to predict and was ultimately not in the interest of users. It was incredibly dumb.

<comment><USER6> The advertisers chosen to ignore DNT. It don't matter if they decided to do so because they disliked the concept of DNT or if they did so because the OS manufactorers decided to change the opt-in to opt-out. The decision was made solely by the advertisers, and there the blame resides.

If Microsoft had not made this choice then the advertisers could still have made the same decision. We will never know, and it doesn't really matter. Its a "what if" situation, and like many such "what if"s we are simply speculating about motives while not looking at the billions of dollar worth of obvious reasons why the advertisers wanted to ignore DNT.

</comment></comment></comment></comment></comment><comment><USER7> As others have mentioned here, this is akin to a sheep carrying a sign saying "please don't eat me", hoping wolves would respect it.

Furthermore, this sheep just highlighted the fact that it's a troublesome sheep, that requires special attention (i.e. if the DNT flag is in the header of the first request to my site, I know I can bust out my adblock-bypassing scripts, and start serving ads differently).

When I worked for [name of major ad-supported company redacted], I specifically asked a senior PM one day why are we ignoring the DNT flag in our products. He said "because that's how we make our money", thought for another second and added "also, everyone else ignores it".

<comment><USER8> The wolf comparison is on point in that advertisers are evil creatures who rely on hurting internet users to survive and thrive.

</comment></comment><comment><USER9> I don't really understand how this is supposed to help. If I'm an advertiser/tracker/etc, what keeps me from adding the policy file to my website - so adblock, duckduckgo etc. are happy - and then blatantly violating it?

The "policy" doesn't seem to be legally binding in any way, there is no way to even detect violations and the EFF itself writes that it can't enforce it:

> _Posting the dnt-policy.txt file makes a promise to the users who interact > with their domain. We believe it would be a false and misleading trade > practice to post the policy without the intent to comply in good faith. > However, EFF is not in a position to enforce this promise or monitor > compliance._ [1]

So what's the point?

[1] [https://www.eff.org/dnt-policy#faq-What-does-the-dnt- policy....](https://www.eff.org/dnt-policy#faq-What-does-the-dnt-policy.txt- promise-mean)?

<comment><USER10> If you're a US company and you lie to your customers about what your policies are, the FTC may well sue you. They do it all of the time over privacy policies.

</comment></comment><comment><USER11> This is from 2015.

<comment><USER12> Yeah, my first thought when I read the headline was "Again?".

DNT was actually pretty widely implemented in browsers for a while, but it ultimately failed because there wasn't anything actually enforcing the standard. It was essentially just a way to politely ask servers not to track you.

<comment><USER13> If Microsoft had't made it the default in IE, then DNT would have been an explicit action to show that you do not consent to tracking, which would have had legal bearing.

<comment><USER8> It had zero legal bearing either way.

</comment></comment></comment></comment><comment><USER14> I seriously doubt this will gain much traction. I would love it to, but I doubt the motives behind advertisers.

I mean, just look at the current state of advertising on mobile. One constantly gets ads hijacking the browser to show ads ostensibly from Amazon or Walmart (I doubt either Amazon or Walmart would actually prevent you from getting to the content you're looking at). The "well-done" ads prevent you from even hitting the back-button on your browser to return to the content. Being an Android user, I've effectively taken to using MS Edge on Android, because at least in Edge, I can disable javascript, which has gone a long way to crippling such ads. (Before anyone asks: I'm normally a Chrome user + UBlock, etc etc, but Chrome doesn't support extensions on Android, and I've never had good luck with FireFox for anything other than draining battery).

When Ad companies learn to play nice and not hijack my browser and occasionally serve up out right malware, maybe, just MAYBE, will I reconsider playing nice with them.

<comment><USER15> You're right. The ship has sailed... _for advertisers_. They'll _wish_ this DNT variant had caught-on, because since then ublock origin and others like it have become significantly more popular, the native-adblock Brave browser is growing slow and steady, and now even Mozilla offers users the option to disable all tracking. Perhaps in another couple of years Mozilla will enable it by default for everyone.

<comment><USER16> Except of course tracking for Mozilla's monetary and advertising partners, like Google. They'll pass that off as part of their Shield Studies and insert hidden tracking plugins into the browser which will be invisible to the user.

<comment><USER17> You'll need to provide some pretty solid proof for that accusation.

Credible Wireshark log dumps would be a good start.

<comment><USER16> Since I refused to downgrade to WebExtensions Firefox, and I'm currently using Pale Moon for most browsing (and I'm looking at Otter as a possible #2), I don't have access to it anymore. I simply do not trust Mozilla anymore, or Firefox.

<comment><USER17> So you have absolutely no proof of any kind, other than paranoid ideas, which fits in nicely with the usual misguided anti-webextensions ranting.

I'm sorry, but if you expect anyone to believe you, you're going to have to produce actual evidence.

</comment></comment></comment></comment></comment></comment><comment><USER18> My issue with DNT is that it is generally another bit of uniqueness that makes my browser slightly EASIER to track for anyone who doesn't care about obeying it, which are likely the greatest threats.

</comment><comment><USER19> If a security or privacy model depends on the cooperation of those on the other end of the wire, it will fail.

<comment><USER20> This is the reason why DNT failed. If it can't be forced, the bad players won't follow it.

</comment></comment><comment><USER21> IMO, tracking should be strictly opt-in, making it opt-out is abusive and ubethical.

I recently learned of GDPR. Although I'm uncertain of the exact law's implementation details, I think it's a step in the right direction. It's strictly opt-in and requires providing a clear explanation of what data gets collected.

</comment><comment><USER22> It is one of these things that it is too little too late. Ad blockers filled in the gap and there is no need for a solution anymore.

Not to mention that AdBlock has lost all the good faith from the users, so including it in the coalition only does damage to the public image.

</comment><comment><USER23> Please don't kill anyone vs. killing is against the law and you'll go to jail if you do it.

I know which one works best.

</comment><comment><USER24> Coalition Announces New "Please Don't Listen" Standard against Man-in-the- middle Attacks

<comment><USER16> Or even better a new, "Please Don't Listen" standard against cell-phone conversations on busy streets!

</comment></comment><comment><USER25> Cool, a new way our browsers can be fingerprinted! Thanks EFF for one more bit of entropy!

Yes I know this was in good faith, but when you are trying to get good faith agreement against the business model of an industry, it's no surprise it was a failure.

</comment><comment><USER26> > Disconnect's partners in this launch are the innovative publishing site > Medium

I know this is off-topic, but what is so innovative about Medium? Does it break any significant ground beyond what LiveJournal was doing almost two decades ago?

<comment><USER27> Nothing. I'm a bit surprised an EFF article is using all those meaningless fluffy words to describe the partners.

</comment></comment><comment><USER28> Could someone clarify: What's the standard? Is it adopting EFF's DNT policy [https://www.eff.org/dnt-policy](https://www.eff.org/dnt-policy)? Is it hosting any privacy policy at /.well-known/dnt-policy.txt? Do any tools or browsers use that URL or display it to users? Has anyone else adopted this standard?

</comment><comment><USER29> The ad bubble and how it affects Google/Mozilla is now one of my favorite topics. It is not just Google, but it is the most interesting.

</comment><comment><USER30> Now all we need if for websites to automatically hide the cookie warning header when DNT is set.

<comment><USER16> Oh, I'm sure that someone out there already does. The question is whether they're making enough money off it to do it en masse.

</comment></comment><comment><USER31> AUGUST 3, 2015</comment>


What Would Jesus Do? He'd Back A Startup - <AUTHOR> http://www.huffingtonpost.com/2012/12/04/christian-tech-entrepreneurs_n_2198154.html?utm_hp_ref=small-business&ir=Small%20Business

<comment><USER2> Jesus was a carpenter. Where would he get the money to fund a startup?

That's only a bit tongue-in-cheeck. That actual title of that piece is "Christian Tech Entrepreneurs Find Funds, Support Among The Faithful", and it makes no comment about what Jesus would do.

This is sort of like socially responsible investing. ("Sort of" could be "is", depending on your views about Christianity.)</comment>


Ask HN: Why are we still using text editors to write code? - <AUTHOR> Software has gotten more and more complex and distributed meaning code is no longer in one place/repo. Yet we rely on code editing capabilities that have not changed much over the last +20yrs. I am seriously puzzled. I thought that by now, we would have progressed onto something else. Than again I find myself using VIM for almost a decade unable to think of what could be truly superior to wrangling some characters in order to produce a functioning program. <comment><USER2> Probably because structured text is expressive, portable, and almost universally readable. And my voice isn't good enough to sing code into being without syntax errors.

<comment><AUTHOR> In a sense this is also true for assembly - what we did here was to abstract away details and finding higher level concepts. I am wondering what is keeping us from leaving text based programming altogether. I know there are several tools that allow some kind of visual programming e.g. Unreal Engine and blender - maybe even Github Actions counts. But they all do not seem to catch on to a wider audience and I wonder why that is.

</comment></comment><comment><USER3> How would a visual compiler even work? You can't really just skip the text layer unless you're willing to be married to one set of paradigms.

Plus, what makes anyone want to bring mechanics into programming?

Look at an internal combustion engine. That's your physical manifestation of visual programming. It's a bunch of blocks of different shapes and sizes fastened together to do a task. It is made no easier to grok without text. The people who can operate on such systems are called mechanics, and even they still need text to reference from time to time.

Part of programming, and arguably where the Art shines through brightest is _linguistic mastery_ through which comes the ability to visualize the System Under Work.

I'm increasingly reluctant to try to teach coding primarily as opposed to computer science. Doing so robs the practitioner of that ability to perceive the visualization of what the code _is_ rather than what the code actually reads as.

To lose that perspective is to be completely out of touch with a program. It's just a bunch of words and desperate flailing to line everything up until the compiler stops complaining. Fighting a merciless djinn hoping that you don't get saddled with the unintended consequences of not realizing what it actually was you were doing.

</comment><comment><USER4> And don't forget if you want a drag n' drop UI -- someone has to code and maintain it regardless.

<comment><AUTHOR> True but only until the 'language/tool' becomes self-hosted.</comment></comment>


Netflix caught censoring Back To The Future Part 2 scene - <AUTHOR> https://reclaimthenet.org/netflix-censors-back-to-the-future-part-2/ <comment><USER2> That edit makes it hard to get the context, and potentially changes the meaning. Unedited, it's clear he's shocked and repeating the title that the almanac changed to. In the edited version, it sounds like Ooh la la is his reaction to what is in the magazine.</comment>


Ruby Tips, Part 5 - <AUTHOR> http://globaldev.co.uk/2014/04/ruby-tips-part-5/

<comment><USER2> My favorite Ruby resources: [http://www.confreaks.com](http://www.confreaks.com) | [http://www.rubytapas.com](http://www.rubytapas.com) | [https://www.destroyallsoftware.com/screencasts](https://www.destroyallsoftware.com/screencasts) | [http://railscasts.com](http://railscasts.com) (dated but still useful) | [https://www.ruby-toolbox.com](https://www.ruby-toolbox.com)

</comment><comment><USER3> I think growing a string with << is an expensive operation. Since once the allocated memory is full, it will cost O(n) to copy the entire string to a new location. If we are carrying out m insertions, this could take O(mn).

The way I have been building strings is to store the m strings in an Array and then join() it at the end (which should be only O(n)). The m small objects need to be allocated in both cases, the only difference being that we hold on to those and join them later on.

Am I missing something? I have never measured the performance on either of the these operations so I could be off the mark here.

<comment><USER4> For the cases I have benchmarked concatenation with << has been faster than join on an array.

Here's a simple benchmark:

        require "benchmark"

        n = 100_000
        Benchmark.bm(4) do |x|
          x.report("<<") do
            n.times do
              "aaaaa " << "bbbbbb " << "ccccc " << "ddddd " << "eeeee " << "fffff"
            end
          end

          x.report("join") do
            n.times do
              ["aaaaa", "bbbbbb", "ccccc", "ddddd", "eeeee", "fffff"].join(" ")
            end
          end
        end

The results I get for this are:

                   user     system      total        real
        <<     0.140000   0.000000   0.140000 (  0.143750)
        join   0.230000   0.000000   0.230000 (  0.228035)

I'd be interested to see if there were any use cases where the relative performance was reversed.

<comment><USER5>
        require "benchmark"
        n = 100_000

        A = "foo " * 20
        B = "bar " * 20
        C = "baz " * 20
        D = "foobar " * 20
        STRINGS = [A, B, C, D]

        Benchmark.bm(4) do |x|
          x.report("<<") do
            n.times do
              "" << A << B << C << D
            end
          end

          x.report("join") do
            n.times do
              STRINGS.join
            end
          end
        end

                   user     system      total        real
        <<     0.090000   0.010000   0.100000 (  0.102411)
        join   0.070000   0.010000   0.080000 (  0.071142)

</comment></comment></comment><comment><USER6> Something in my computer-science-student background feels unsettled when I can use a language for years and still learn new tricks (or often, that I've forgotten that I've learned) about common functionality such as string interpolation...but I do love a lot of Ruby's tricks.

        if path =~ %r{^/assets/mobile/img}
           ...
        end

I knew about `%r` but hadn't realized that it escapes forward-slashes while leaving other regex symbols intact. But with the previous explanation of `%q`, in which arbitrary delimiters can be used, it makes sense...curly braces simply replace `/` as the delimiter, and `/` simply retains its non- specialness in regex...saves me a lot of writing `Regex.escape("/path/to")`.

Another regex notation that I recently learned (elsewhere) and now love to abuse:

         "He is 32-years old"[/\d+/] # => "32"

as opposed to:

         "He is 32-years old".match(/\d+/)[0]

<comment><USER7> The extension of that can also be handy and is often overlooked. Contrived example:

        "28 men are 32 years old"[/(\d+) (year|day|month)/, 1] # => "32"

</comment></comment><comment><USER8> These are some good tips. If you are into the Ruby language and want more, I recommend checking out Ruby Tapas [http://www.rubytapas.com/](http://www.rubytapas.com/) . I have no affiliation with it, just happy customer.

</comment><comment><USER9> notice that this is wrong

        x ||= y # equivalent to:
        x || x = y

it's actually something slightly different (or at least it was some years ago).

<comment><USER4> Here's an example that shows x ||= y behaves like x || x = y, rather than x = x || y

        class Foo
          def foo=(object)
            puts "foo= called with #{object.inspect}"
            @foo = object
          end

          def foo
            puts "foo called"
            @foo
          end
        end

        puts "x || x = y"

        a = Foo.new

        a.foo || a.foo = 1
        a.foo || a.foo = 2

        puts "\nx = x || y"

        b = Foo.new

        b.foo = b.foo || 1
        b.foo = b.foo || 2

        puts "\nx ||= y"

        c = Foo.new

        c.foo ||= 1
        c.foo ||= 2

This outputs:

        x || x = y
        foo called
        foo= called with 1
        foo called

        x = x || y
        foo called
        foo= called with 1
        foo called
        foo= called with 1

        x ||= y
        foo called
        foo= called with 1
        foo called

and you can see that the output for ||= matches the output for x || x = y

<comment><USER9> I didn't mean that it is "x = x || y", I meant "it's completely ad hoc".

For example, if you try "x || x = y" you will get an exception if x is not defined, but "x ||= y" will work fine. The same is true of constants "X || X = 1" will explode while "X ||= 1" will work fine.</comment></comment></comment>


Ask HN: any viewable application videos from YC companies that got accepted? - <AUTHOR>

I am applying for the winter round of yc and was wondering if there any available videos from people who got accepted into yc.  I would like to view them. <comment><USER2> Dropbox "single" founder application: <http://files.getdropbox.com/u/2/app.html>

(Sorry, I just noticed you asked for video. There's a screencast, but that was before 1 min videos were introduced.)

</comment><comment><USER3> I saw a link to one before, but I can't seem to find it now. I'm interested to know what about the video is important.</comment>