Joel Spolsky's talk at Yale, part 2 - <AUTHOR> http://www.joelonsoftware.com/items/2007/12/04.html

<comment><USER3> In-house programming doesn't need to be as bad as Joel's experience. Yes, you are in what is called a "cost center" that doesn't get the same management priority as a "revenue center." But the more closely your work is aligned with a revenue center, the better treatment you'll get.

In a software company, you're in a revenue center. The problem is that you may have to sign a draconian intellectual property agreement, jeopardizing side projects. This is less likely as an in-house programmer.

</comment><comment><USER4> In-house programming is usually worse than product progamming, but there are exceptions.

Some companies really do see their in-house programming as critical for success, and treat it accordingly. I get the impression that NetFlix, for instance, is a pretty good place to be a developer, because the company sees logistical software (for optimizing DVD delivery) as a critical components in winning against blockbuster (they also do video downloads, from what I've heard, but that's so close to an actual software product that I'm not sure I'd call it "in-house"). I gather that Amazon is also pretty innovative, but I don't know anyone who works there.

On rare occasion, product companies are clueless enough to treat their developers like typists - I've been at exactly one. The difference, of course, is that these companies don't really last long. A textiles company with crappy software management practices can survive anyway, whereas a product company with that attitude will almost certainly fail, and quickly.

So in general, I agree - though there are some notable exceptions.

<comment><USER5> I don't think Netflix qualifies as in-house programming. IMO, when Joel refers to in-house programming, he refers to companies that have a core competency that has nothing to do with software.

If you work at an insurance company or tech support company, you'll be writing code to make lives easier for people who work at the company. Your customers are in-house employees.

</comment></comment><comment><USER6> Given my current employment situation, I'll just say that his remarks in this part of the talk are painfully correct.

</comment><comment><USER7> Why not try to be an in-house developer for a big universities?

I haven't tried it out yet but I think it might be fun. Less pressure/stress/deadline and huge opportunities to roll-your-own web-app for students (in the area of 20-40k students). Salary wise is also great (especially those government funded universities).

<comment><USER4> I did this for a while. There are some good aspects to this job - you tend to get plenty of vacation, futher education and conferences are well supported. Salaries are only the low side in my experience, definitely not great - <USER2> when adjusted for pensions and stability (very difficult to get fired), there isn't much to complain about.

There are also some really horrible elements to this job. For starters, the stability - which sounds great - means that you will truly be surrounded by dead weight. Utterly unmotivated people work in some of these departments. It really got to me, to the point where I couldn't stand to be there anymore. A pension is great, but I'm not going to hover around for 30 years in a spiritually dead place (I'm not exaggerating here). I'll find another way to save for retirement.

Another problem is that the jobs almost never lead to the top. There are a few CIO/style or "Chief Architect" style jobs at universities, and those are pretty sweet gigs for those who get them. But if you have a job in a non- academic department, you're definitely a cost center, the definitive in-house programmer. There are _very_ interesting projects in academic departments, but expect what I'd call a "parchment ceiling" - ie., you can't progress without the right degree. In a software company, people seem to like grad degrees, but if you can bring it, they'll put you in a high impact position with a lot of creativity and automony. At a university, the Ph.D grant-holder is in charge. Period. The dev is more or less a (decently paid and well appreciated) paraprofessional.

This was just my experience (I worked for a university as a dev for almost 3 years). Overall, I'd say that unless you _really_ want the stability, don't do it.

<comment><USER7> I agree with your statement regarding "unmotivated" people.

I'm currently working part-time at school just for fun and to have the experience of how it feels working there. This isn't a "research developer" kind of job but really IT job, developer.

Sometime it is hard to convince your boss that his/her approach was wrong in terms of software engineering point of view.

I like how people don't work overtime and sometime leave early :). Might be good to start a startup or get a consulting side-job there since there's no NDA or whatsoever to be signed (at least in my place). Plus you'll get to know in which area you should write your own software and sell it to them in the future.

</comment></comment></comment><comment><USER8> This was a much more interesting (and painfully accurate) portion of the talk (I assume it is just one talk, just reporting it in 3 parts). Lots of stuff he has mentioned years ago, but slightly refined (fine with me - Joel always makes me optimistic that things can be better and should be and will be).

</comment><comment><USER9> This is exactly the one big fear I have as I'm beginning my career in software. I _really_ don't want to end up sitting in a cubicle coding boring ass software for the next 40 years...

</comment><comment><USER10> Not a big fan of the Joel on Software but this is an amazing article... ...I used to be one of those "house programmers" too!

<comment><USER11> I'm an in-house programmer (left grad school because I thought I'd get some money). The job is painful. The layers of bureaucracy are suffocating. It probably doesn't help that I'm actually working for contractor that produces in-house software for the federal government.

Oh well, at least its expected that an employee will move around a bit.

<comment><USER5> The way to combat that is to convince your bosses that you completely understand why the business exists (to make money). Convince them that they can use technology to be better at that and the job will become a lot more interesting and fun.

If you're going to be stuck doing something shitty, it's well worth the effort to try and make it less shitty.

<comment><USER12> ...until the auditors come in and tell you the shareholders don't like you innovating like that.

Trust me, even when your bosses are onside, in-house programming is a PITA. You're better off talking to your boss about how the product you made on your own is better than some of their in-house stuff, and that he/she should buy it.

Of course, that's got it's own set of problems.

<comment><USER5> Yeah. I've got a startup that's two weeks from launching (soft launch unfortunately) and I'm unbelievably excited about it. I'm giving this everything I've got because I don't think I can go another year or two not doing my own thing.

I currently work as an in house guy and it really is a PITA.

<comment><USER12> I'm with you. Good luck in your venture. Make sure you let us know how it turns out!</comment></comment></comment></comment></comment></comment>


Ask HN: Software Developer Hours/Salary at your firm? - <AUTHOR>

<comment><USER2> ~8 hours and 15 minutes of work, 5 days a week.

~$50k a year.

Where I live, that'd be similar to getting paid ~$75 to 80k a year in the Bay Area.

<comment><USER3> In the bay area that is considered pretty low unless it's a startup with significant equity.

<comment><USER4> On the contrary, that's right in line with what I've seen as entry level salaries for college grads (not Stanford grads) in the Bay Area.

</comment></comment></comment><comment><USER5> H1B salary data is public so it's probably provides the most reliable source of data for larger companies.

</comment><comment><USER6> Generally ends up being around 8hrs/day 5days/week. ~110K/year Greater Seattle Area

<comment><USER7> Is the cost of living in Seattle high? How much is the take-home post-taxes, etc.

</comment></comment><comment><USER8> This may vary quite a lot considering experience.</comment>


India and Bangladesh have begun the exchange of over 160 enclaves - <AUTHOR> http://www.washingtonpost.com/news/worldviews/wp/2015/08/01/say-goodbye-to-the-weirdest-border-dispute-in-the-world/?tid=HP_more?tid=HP_more <comment><USER2> Surely not as weird as the Bir Tawil border dispute between Egypt and Sudan. Both argue that it should be part of the _other_ country!

[https://en.wikipedia.org/wiki/Bir_Tawil](https://en.wikipedia.org/wiki/Bir_Tawil)

<comment><USER3> That one seems pretty straightforward. Each country's preferrence nets them more land. Bir Tawil is far less valuable than the larger disputed landmass (being baren rather than bordering a navigable body of water) so neither party seems to care to fight over it.

<comment><USER4> Still strange when a country actively rejects a stretch of land.

<comment> Tuna-Fish Accepting it would mean legitimizing the border treaty that costs them the larger stretch of land. Stranger things have happened.

<comment><USER5> Could I murder someone there, and no nation/state 'could' prosecute me?

Not an actual plan, mind you, just curious if there's some form of international law that ultimately covers these places.

<comment><USER6> Some truly awful crimes go on at sea and the criminal simply walks away. If you can arrange to do it there, you could try your luck.

In theory, at the very least, the flag state of the vessel should do something about it. In practice, if you pick the right flag state, the right ship, you could get away with it. Some very suspicious deaths go essentially unnoticed on merchant ships, and I know a security chief on a cruise ship who has arrested people for serious sexual assault and the flag state just doesn't care and/or just doesn't have the capability to investigate; they get put ashore at the next port and walk away scot-free. It happens, regularly enough that it's not an unusual thing.

<comment><USER7> >and the criminal simply walks away..

I think 'sails away' would be more apt.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Were the borders actually disputed, or just really weird? The article made it sound like while the borders were odd, both countries agreed on where they were.

<comment><USER9> The way I got it, they were just weird.

</comment></comment><comment><USER10> The article discusses enclaves extensively, and then refers at the end to "exclave residents". Wikipedia ([https://en.wikipedia.org/wiki/Enclave_and_exclave](https://en.wikipedia.org/wiki/Enclave_and_exclave)) says:

> An enclave is any portion of a state that is entirely surrounded by the > territory of one other state. An exclave is a portion of a state > geographically separated from the main part by surrounding alien territory. > Many enclaves are also exclaves.

If I understand this correctly, the WaPo article really means to refer specifically to exclaves, not just to enclaves, throughout.

<comment><USER11> I think "Many enclaves are also exclaves" is backwards. By Wikipedia's definition, _all_ enclaves are exclaves, but only some exclaves are enclaves.

The territories described in the article are enclaves, not just exclaves, because India and Bangladesh are the only two countries involved.

EDIT: Ah, never mind, I was only considering the case where a country is partitioned into multiple disconnected components.

<comment><USER12> Not _all_. Look at D. If the entire territory of a state is an enclave, then it's not an exclave of anywhere.

e.g. the Vatican City.

<comment><USER13> Lesotho and San Marino are the only other two, I think.

<comment><USER14> Well, there's the Republic of Kugelmugel.

[https://en.wikipedia.org/wiki/Kugelmugel](https://en.wikipedia.org/wiki/Kugelmugel)

</comment></comment></comment></comment></comment><comment><USER15> Even within the US, state borders are still not a settled matter.

[http://mobile.nytimes.com/2014/08/24/opinion/sunday/how- the-...](http://mobile.nytimes.com/2014/08/24/opinion/sunday/how-the- carolinas-fixed-their-blurred-lines.html?referrer=&_r=0)

<comment><USER16> Thank you, that is a great article! Recommended for any map geeks.

I love these two bits in particular:

> In another segment, researchers found a stone boundary monument that had > been set as part of a 1928 resurvey, except it now stood near a tee on a > golf course. Officials at the course had moved it years before so duffers > could brag about their two-state tee shot. Using the original 1928 maps, > advanced mathematics and some informed guesswork, the joint survey teams > navigated to the exact spot where the monument had been uprooted, and even > found its broken-off base.

> But an obvious fix is not in sight for Lewis Efird, who bought a gas station > just south of what he thought was the state line in the early 1990s to take > advantage of South Carolina's significantly lower gas tax, as well as the > ability to sell beer and fireworks. Unfortunately, the survey work showed > conclusively that his pumps were in a part of North Carolina where gas is > more expensive, beer sales are not allowed and fireworks are illegal. As he > told commissioners in a public meeting, "Our business is going to be > destroyed."

<comment><USER15> That gas station is likely to get an exemption as part of the border resolution: [http://www.wcnc.com/story/news/politics/2015/03/27/state- lin...](http://www.wcnc.com/story/news/politics/2015/03/27/state-line-debate- nears-end-for-north-carolina-and-south-carolina/70568322/)

</comment></comment></comment><comment><USER17> An other very strange case: This isle is managed by both France and Spain which control the island for alternating periods of six months: [https://en.wikipedia.org/wiki/Pheasant_Island](https://en.wikipedia.org/wiki/Pheasant_Island)

</comment><comment><USER18> For a great explanation of the enclaves and exclaves described in the article, you might like to check out this youtube video: [https://www.youtube.com/watch?v=gtLxZiiuaXs](https://www.youtube.com/watch?v=gtLxZiiuaXs)

The visual aids definitely help.

</comment><comment><USER19> And here's an example of a tiny exclave that was not only completely separated from a "mainland", but also surrounded by the country extremely hostile to it: [https://en.wikipedia.org/wiki/Steinst%C3%BCcken](https://en.wikipedia.org/wiki/Steinst%C3%BCcken)

Between 1949 and early 1970s the only way to get there was with a helicopter (they even later installed a monument to it in there).

</comment><comment><USER20> I wonder how was life for people living in one of those enclaves. Were there actually passport controls at the frontiers? My guess is that the Indians living there were actually living just as if they were citizen from Bangladesh, but I could be wrong.

<comment><USER21> you are almost certainly correct but there's a possibility that folks could be hassled etcetera: taken advantage of basically.this is a part of the world where the basic things we rely on don't exist institutions rights etcetera

<comment><USER22> Aside: > we

everyone isn't in a developed region

</comment></comment></comment><comment><USER23> Here is the detailed area containing the third order enclave on google maps: [https://firstname.lastname@example.com,88.7641825,16z](https://firstname.lastname@example.com,88.7641825,16z)

</comment><comment><USER24> So this must be the Cooch Behar from the Threepenny Opera's "Kanonensong" [https://www.youtube.com/watch?v=gi433VgJ5bc](https://www.youtube.com/watch?v=gi433VgJ5bc) , right?

</comment><comment><USER25> Also, this: [https://en.wikipedia.org/wiki/Enclave_and_exclave#Enclaves_w...](https://en.wikipedia.org/wiki/Enclave_and_exclave#Enclaves_within_enclaves)

</comment><comment><USER26> What kind of extremely screwed up design for mobile is on that site? A left and right column that scroll independently of each other. Can't resize the text. Can't enable the reader mode either.

</comment><comment><USER27> Reminds me of Baarle-Nassau : [https://en.wikipedia.org/wiki/Baarle- Nassau](https://en.wikipedia.org/wiki/Baarle-Nassau)

</comment><comment><USER28> wired

</comment><comment><USER29> There's at least one piece of Germany inside of Switzerland: [https://en.wikipedia.org/wiki/B%C3%BCsingen_am_Hochrhein](https://en.wikipedia.org/wiki/B%C3%BCsingen_am_Hochrhein)

There are a few others: [https://en.wikipedia.org/wiki/List_of_enclaves_and_exclaves](https://en.wikipedia.org/wiki/List_of_enclaves_and_exclaves)

</comment><comment><USER29> I don't mean to derail the discussion, but the Indian Nepalese and Bhutanese people are so beautiful.

I know that they're discriminated against in India. One would hope India would have a higher regard for all of their citizens (not just based on beauty of course).</comment>


Opinionated Comparison of React, Angular2, and Aurelia - <AUTHOR> https://github.com/stickfigure/blog/wiki/Opinionated-Comparison-of-React%2C-Angular2%2C-and-Aurelia <comment><USER3> I've spend a lot of time evaluating Angular + Ionic, Vue and React. My goal is to rewrite my webapp as a SPA with complimentary mobile apps. Maximum code sharing would be nice. I'd like to add to the discussion what I learned and also add Vue for comparison.

Vue felt less intimidating at first, whereas React seemed to be overly complicated. Truth is, both are actually quite similar. The problem is that every single tutorial out there tells you: "React is only the V in MVC" (and so is Vue) but then goes ahead and implements all business logic in Components. I found it incredibly hard to learn about a sane (SPA?) software architecture. Some people throw in Redux and Vuex, but they actually only manage the state of the application. This is not where business logic goes.

Note: I haven't found a proper solution yet. Or let's call it this way: People dump their business logic in components and Redux and that works just fine to some degree, but they actually treat React more than the V in MVC. Just be aware.

React isn't that complicated, especially if you start out with functional stateless components, i. e. Components that only have a render function, props and no internal state. This helps to think about where state and logic should go and once you implement your first React components this way, you see that there's hardly any difference between Vue and React. Vue might let you even produce code that is more ugly than what you'd have produced with stateless components in React.

The beauty of React is that it forces you to think in a slightly different way. Vue seemed more accessible for a spaghetti code writer like I was (am?), but it wouldn't really challenge me in the same way like React does. Vue made me understand what _reactive_ is all about, React helped me to think about _state_ more clearly, especially if you want to slowly transition to functional programming.

Angular is often seen as a full application framework – and to some degree, that's true. But I suspect you'd gain a lot if you actually wrote your core application / business logic as if it wasn't part of Angular to make it more shareable. For example, if you want to go mobile with Angular, you could use Ionic, but it's not 100% compatible both ways and you must think of a way to structure your app so that certain parts (the model) is actually independent from the framework.

You could treat Angular more as a View-layer thing, which simply attaches a bunch of observers to your app state, which reduces the need for many APIs Angular offers and also reduces its complexity.

The OP wrote about dependency injection, which I found odd as a comparison metric. DI is a design pattern to solve a specific problem and React/Vue simply don't apply to this design pattern.

The main advantage of React over Vue and Angular is: React Native. Vue doesn't have anything close to it. Weex might be there one day, but right now, the docs are very incomplete, half in Chinese and I think it lacks a lot of components React Native already has. With Angular, the logical framework to build hybrid apps would be Ionic. Ionic is nice for specific cases: When your app is read-only!

This isn't about performance (it's solid on newer devices) – it's forms and input controls. This is where Ionic shows the ugly side of the underlying Webview: Mobile Safari simply sucks for things beyond a simple input field. Want to show a picker for the date that only shows 15 minute intervals? Good luck with that. An input field that allows decimal only? Your best bet is _type=tel_ and neglect the decimal point separator. Or use the rather un- performant and ugly DatePicker that comes with Ionic.

But this is a thing where even average users notice a difference to native input controls. If your app is mostly read-only with nothing more than a button and a toggle as input controls, by all means, go with Ionic. Have a form in it? Make a minimal prototype with just this form and see for yourself how it plays out.

React is _learn once, write everywhere_ , because you can't really share any component-related code between React and React Native. In React, you use HTML elements, in React Native, you use native elements.

<comment><USER4> > The beauty of React is that it forces you to think in a slightly different > way. Vue seemed more accessible for a spaghetti code writer

This has been my experience too with React and Vuejs. React requires thorough planning beforehand to write good code. You need to plan the parent-children structure before you jump in. It's easy to write shitty code in react too if you jump in headfirst; resulting in the kind of "enterprise boilerplate" others are talking about in this thread. Personally, I am happy with React at the moment (and React Fiber let's you return an array of components, so no more wrapping your components around a span - yay!).

<comment><USER5> I haven't tried React but I felt the complete opposite with Vue. I've never written more beautiful front-end code than what I've done in Vue. Did you use .vue files? Did you use a proper state tree like Vuex?

</comment></comment></comment><comment><USER6> > There are a few more frameworks I would have loved to try, including Polymer > and Vue.js. There just wasn't enough time to do a deep dive with all of > them.

I hope he gives Vuejs a try. As a javascript beginner, who tried Angular, Angular2, A bit of React and VueJS, I just loved the flexibility and approach of VueJS. I was instantly productive thanks to the amazing documentation and vue-cli that just worked out of the box setting up my project.

PS: Never really spent much time on React as I tried it after VueJS and did not feel like proceeding much further with my tests.

<comment><USER7> I wish the author had tried Polymer because it's the most underrated one. I just love the way Polymer components declare/consume dependencies (as tags in the component file) and connect all sub-components in the template markup via attributes - It makes data binding relationships between components and their children very clear.

Polymer is basically an inverted version of React (and it achieves a similar outcome). In React, template markup is nested inside the code. In Polymer, code is nested inside the template markup.

I really like React but I wouldn't use it for a personal project knowing that Polymer exists. I hope Polymer will gain more traction because I would love to be able to use it professionally.

<comment><USER8> Polymer traction is looking good, over 7k people on slack channel, 750 elements on webcomponents.org. And they got first day on google IO this year, youtube main site is being rewritten in it, ING, IBM, GE are using it, so it gets quite a bit of love from enterprise too.

<comment><USER7> I feel more comfortable using technologies that have had moderate, steady growth in popularity over many years like Polymer than technologies which experienced sudden, explosive growth like Angular 1 (we know how that turned out).

Early explosive growth means that the technology is hype-driven; adopters haven't given themselves the time to critically and objectively evaluate the solution - It's not so different from economic bubbles. People get excited and buy into it without thinking and then at some point in the future when they realise that it won't live up to their expectations they all start selling at the same time.

</comment></comment></comment></comment><comment><USER9> > And the React ecosystem tends to either lack typings or provide poor/broken > typings.

React integrates really well with flow[1] (which is not surprising because they're both developed at Facebook) and in my experience flow's typesystem is more powerful (OCaml inspired) than TypeScript one (C# inspired):

\- non-nullable types by default is a big deal (they added support for non- nullable types in TypeScript 2, but enabling it with `--strictNullChecks` is a breaking change, so I don't think many users have done the switch).

\- the type checker is sometimes not strict enough to be sound [2].

[1] : [https://flowtype.org](https://flowtype.org)

[2] : [http://djcordhose.github.io/flow-vs- typescript/2016_hhjs.htm...](http://djcordhose.github.io/flow-vs- typescript/2016_hhjs.html#/21)

<comment><USER10> > React integrates really well with flow[1] (which is not surprising because > they're both developed at Facebook)

It can integrate just as well with TypeScript.

> flow's typesystem is more powerful (OCaml inspired)

It lacks access control for class properties/methods, I wouldn't call that powerful. [https://flow.org/en/docs/types/classes/](https://flow.org/en/docs/types/classes/)

<comment><USER9> > It lacks access control for class properties/methods, I wouldn't call that > powerful.

You mean `private` and such ? Well JavaScript don't support taht either yet, and flow is a type-system for JavaScript, it's not a new language on its own.

About the «powerful» word: Flow has had an algebraic data type (ADT) from the beginning, the kind of type system you'd find in functional programming languages, whereas TypeScript has and Object-Oriented type-system (à la Java or C#). ADT are usually considered «more powerful» since it offers more ways to write logical invariants in your code. The recent versions of TypeScript tries to retro-fit some features of ADTs into it, like non-nullable types or sum types, but it's a bit hacky IHMO[1].

[1]: [https://www.typescriptlang.org/docs/handbook/advanced- types....](https://www.typescriptlang.org/docs/handbook/advanced- types.html#discriminated-unions)

<comment><USER11> Typescript has had Discriminated Unions as long as I can remember (pre 1.0). Why do you think they've been hacked in?

</comment></comment></comment></comment><comment><USER12> The ending is what makes this article:

>Overall, I'm not 100% sure I made the right choice, but I only have to live with it for two years.

People are great at short term thinking, and tend to be terrible at long term thinking. Just some anecdata: I had a look at some source code for a 10+ year old web app before JS libraries were popular. I could understand perfectly how a click on a link resulted in a URL hash change and how the hash change resulted in updates on the page. Nowadays it would be written off as coding your own framework since web developers can't be trusted to code without a framework anymore. But it worked with the least amount of indirection possible and it was simple to understand 10 years later. Web apps today just get rewritten every two years.

<comment><USER13> Don't worry, the simpleness and adequateness of plain old JavaScript (+ maybe jquery) and basic web techniques is re-discovered like every 5 years. Right now, we're at the height of the React hype cycle which just means we're approaching its imminent downfall due to generational forces (though I still do like some aspects of React specifically).

Sorry to sound defaitist, but like you say, the goal of React (and AngularJS, vue, ...) is to simplify web frontend development and improve maintainability. But these cost benefits are offset by their (absurd, IMHO, for most use cases) upfront complexity and thus can't possibly be attained within two years. Also, the desire to work in an agile fashion where everybody should be able to do everything (back- and front-end work) works against expert/thermonuclear front-end development tools.

<comment><USER14> A critical point about these types of frameworks it that their benefits wont necessarily outweigh the complexity they bring to every project, and specifically they are likely to be needlessly complex in smaller projects.

In larger or long-term projects though the ability to use formal conventions to break down an app into components that have solid documentation already written on how to do this or that in a way that will scale and extend is quite valuable.

Additionally being able to reach out to a large community of developers who use similar conventions and plugins is quite valuable for troubleshooting those 10%/90% problems or finding a drag-n-drop solution that's compatible with your stack.

</comment></comment></comment><comment><USER15> It just shows how fast the web moves (or how old I am) that someone can write "Then the Web happened...pages were giant jumbled messes of template and jQuery."

There were plenty of new paradigms and new headaches before the JQuery era!

<comment><AUTHOR> OP here. My first draft of the intro was a long-winded history that went all the way back to Win16 thunking. It was too long and detracted from the point of the article, so I cut it down.

<comment><USER16> I'd actually like to see that history as another post, then :) Last fall I did a presentation called "The (R)Evolution of Web Dev", which covered a brief history of web dev technologies and gave an overview of modern web dev tech and trends: [http://blog.isquaredsoftware.com/2016/10/presentation- modern...](http://blog.isquaredsoftware.com/2016/10/presentation-modern-web- dev-overview/) . I also ran across a couple similar presentations recently: [http://www.bcssouthwest.org.uk/presentations/MikeEvans2016.p...](http://www.bcssouthwest.org.uk/presentations/MikeEvans2016.pdf) and [https://hackernoon.com/modern-web-development- bf0b2ef0e22e](https://hackernoon.com/modern-web-development-bf0b2ef0e22e) .

Anyway, excellent post. I'm actually a Redux maintainer, and spend a lot of time answering questions about use of React and Redux. I'd be happy to chat with you sometime about any React+Redux-related topics or questions you might have. I'm @acemarke on Twitter, and also in the Reactiflux chat channels at [https://www.reactiflux.com](https://www.reactiflux.com) .

</comment></comment></comment><comment><USER17> > Angular's routing seems to involve "one big routing config".

That's wrong. You can split the routing configuration just like in react- router or Aurelia. It also supports lazy loading of child routes and components. So you don't have one giant application to serve at bootup time. It is also documented really well: [https://angular.io/docs/ts/latest/guide/ngmodule.html#!#lazy...](https://angular.io/docs/ts/latest/guide/ngmodule.html#!#lazy- load)

<comment><USER18> I was re-structuring the routing in an Angular 2 app yesterday and I came to the same conclusion as the author. I think the documentation in the routing section doesn't go into enough detail about how to configure the modules for the desired encapsulation. The documentation you've posted is what is required - but it's in module not routing. It's hard to find.

<comment><USER19> Angular core team here, we're restructuring some of our docs at the moment and this is super useful feedback. Thanks!

</comment></comment></comment><comment><USER20> I really like Aurelia so far. It offers me a lot of tools as a developer to develop projects my own way.

It feels like working with raw ES6 with a small but powerful library on top. Anyone good Javascript developer can pick it up in a matter of a few hours which makes onboarding very easy.

It is still young and small when comparing it to its big brothers but you should try it anyway. It's really a joy to work with.

I keep reading about how there is no community but that isn't true at all. The Gitter chat is very active and you can get an answer there in a matter of minutes.

\----

My answer to the article's conclusion:

"My team is small and doesn't have a professional web designer; I need other people's components."

\- In my experience using other people's components is often the weakness in big projects. You end up spending more time customizing them to your need than it would have taken building them yourself using the project's specification. That being said, yes, you do need either a full-stack or a front-end dev. for that.

"I also hit too many stumbling blocks building out my spike, requiring hours of painful research."

\- The building system is very simple and looks like the ones I do myself but bigger. You can choose between Webpack and JSPM. You can even use their very simple CLI if you are not used to front-end build systems.

"I never did succeed at getting a dialog to open, show a progress bar, and close programmatically."

\- ... Really? That's the basic tutorial on their website. Was an attempt even tried?

<comment><AUTHOR> _That 's the basic tutorial on their website._

No it isn't. The basic tutorial raises a dialog with a close button that the user clicks.

Try raising the dialog, advancing a progress bar, and closing the dialog - <USER2> without user interaction. Eg, you're showing progress for an activity that should block out all interaction. It just doesn't work.

<comment><USER20> The search grid that I have built using Aurelia does that.

It's been a while so I don't have the exact code in my head. I simply modified the progress bar of the tutorial so that I can pass a parameters that make it so nothing can be clicked if it is set to "true" and also binds the "disabled" parameter of the buttons in the dialog.

I don't want to be "that guy" but how is any of this hard? Everything is open source, you can modify everything to your requirements and build the parts that don't exist.

</comment></comment></comment><comment><USER21> This kind of comparison is meaningless. Compare React to Veu.js, as these are both view renderers, not full MV* frameworks. And compare Angular2 to Ember (with Fastboot), both of which are opinionated MV* frameworks. Not sure why this is on the front page

<comment><USER22> I found it interesting and he specifically pulled in react-router to get the balance needed for the comparison to be valid.

<comment><USER17> When your application is just some views plus some routing - then that would be a fair comparison. But in most real world situations (SPA) it's much more: Form validation, Data Fetching, Unit Testing, Component styling, Translations, Modularization, ...

<comment><USER23> Obviously therefore nobody writes real world SPAs with React.

/s

</comment></comment></comment></comment><comment><USER18> This article is spot on. I've been building Angular 2 and React (Native) apps over the last 3 months and I have broadly similar conclusions. Once React clicked, it really is very easy to reason about.

With regard to the DI problem, I created a combination of static classes for things like the User object and function collections with observables for app state. I didn't use Redux. You can get similar behaviour with Observable zip/scan/reduce and it's much more lightweight.

</comment><comment><USER24> > Save the global components off as global variables and just use them ... > When my ActivityIndicator component mounts, it saves itself off to a global. > Any code can import busy and run busy.start() and busy.stop().

What is the story that FP folks need to tell here, so that people don't do things like this?

<comment><USER25> Nothing. We know it's messy, but React doesn't really provide a better way of doing this.

Context is barely mentioned in the docs, "not recommended" by the devs. Redux is incredibly verbose and overcomplicated. Passing "global" things down in props is just madness (if everything needs it).

Personally I use context, or a singleton (which is just a hidden global really). It's naughty, but usually required for one or two things per application.

FP folks aren't sages hiding in caves who we all wait to come down from the mountains once a year with their crusty wisdom...

<comment><USER26> Passing data via props has never been a problem for me. It's explicit, the chain of dependencies explicit, the data flows in one direction, and components can still be dumb while letting us push the glue layer all the way to the top.

No one has ever approached that code and been confused or had issues tracking down bugs in my experience.

I agree it's ugly. I've found it triggers the same sense in a lot of developers that make them over-abstract code to achieve DRY at the expense of simplicity (this is just an observation, I don't have an opinion on if it's good or bad!).

</comment></comment></comment><comment><USER27> Aurelia is componentised, so you can use React as the view engine which (in theory) would give you the benefits of React alongside decent routing and DI (which can also be swapped out).

One other thing that Aurelia is good about is not requiring a lot of DSL. The maintainers aren't interested in developer lock in or mindshare like Facebook and Google, so the code you write is more portable than with React or Angular - it's a shame the author didn't make more of this.

Additionally the maintainers provide guarantees that they won't pull the projects, which Facebook and Google do not.

That said, it's hard to argue that the ecosystem around React+Redux and Angular makes it very hard for the smaller players to get a look in for all sorts of reasons.

</comment><comment><USER17> Comparing plain React with Angular and Aurelia is completely useless. You cannot write a big serious application with Form Validation, Data Fetching, Testing, etc, just with React itself. A fair comparison would be to write a whole "real world" project and then see what parts you have to use and learn to be able to write a full React application.

<comment><USER23> Author didn't compare "plain React". Author compared React with React Router (and possibly Redux/whatever for state).

Did you only read the part about the documentation?

<comment><USER28> I doubt the author was using Redux if he was praising React and Typescript...

<comment><USER29> Why? I've used Redux and TypeScript together before. They make a really nice combination.

</comment></comment></comment></comment><comment><USER30> I'm working on my first Angular2 app (inside Ionic 2) and have not been overly impressed. Most (all) of these will be first-project-pain but I'll list them anyway:

* The massive coupling in app.module.ts and app.component.ts

* Coming as a backend dev, the coupling of services to the view layer

* Terminology of service/provider, and the general standard of documentation (3rd parties are far better than the official docs)

* Having a definite 'Angular way' of doing things, but not documenting it explicitly

And new to a modern JS project:

* Observables need a mindshift,and I'm still adjusting * Keeping clean separation between layers. Subscribing to events to update viewmodel attributes helps, but I feel I'm lacking separation and over-coupling

Of the example code samples I've adapted, I've found the Aurelia community to be consistently high quality and well thought through, which can't be said for Angular.

<comment><USER31> "* Having a definite 'Angular way' of doing things, but not documenting it explicitly"

Here you go [https://angular.io/docs/ts/latest/guide/style- guide.html](https://angular.io/docs/ts/latest/guide/style-guide.html)

</comment></comment><comment><USER32> I know yet another Framework but a lot of your issues I think are solved with Vuejs as they provide a quite mature and well documented component library which is using Streams (under the hood) and their single-file approach solves a lot of issues ([https://vuejs.org/v2/guide/single-file- components.html](https://vuejs.org/v2/guide/single-file-components.html)).

additionally, they provide their own router, redux implementation which are all working very well with the components.

I think Vuejs has some great approaches which makes it easy especially for people who want to use new frontend stuff but not with the complexity and technical depth Angular2, React and others introduce.

</comment><comment><USER28> /me Quietly goes back to using Knockout and Typescript to happily pootle along building apps without worrying about routing, SPAs and other added complexity.

Simplicity brings its own rewards.

<comment><USER33> In my experience, this initial added complexity and learning curve results in significantly higher productivity once a comfortable knowledge level is obtained. I can't imagine going back to Knockout and I truly believe I can develop 2x with React and it's ecosystem.

</comment></comment><comment><USER34> Been using Vuejs for a couple of months now. Just love it's simplicity and flexibility. Tried Angular 2 earlier. It was ok. But they've lost it with their new release cycle. I guess people will hesitate to use it.

Needed a routing solution where we had to load list-> multiple details(multiple tabs from a list of items; loaded using ajax/websockets) not single detail view. Not sure either Angular or Vue's router could do it. So we ended up implementing a custom one.

<comment><USER19> FWIW, Angular's release cycle is roughly based on the same cadence as React :)

<comment><USER34> :) Wasn't aware of that. Haven't tried React. Maybe because I am a bit impatient.

</comment></comment></comment><comment><USER35> My key to success with react-router was to use context and redux to get props to the routed components. Sub-components from there can accept props directly. After a while it feels natural - any necessary information is stored in the store.

<comment><USER36> This is an anti-pattern unless you actually have shared state between pages. Otherwise it's functionally no different to just having local state on each page and all you have is lots of unnecessary boilerplate.

This is way more common than I realised before I started working in teams. Each page does it's own API calls to the server (either directly, or more commonly through some sort of horrible misuse of redux-thunk), stores the data in it's own little section of the redux store, and then receives the exact same data back as props :/

<comment><USER35> In general, you only need react-router if you have multiple pages with some kind of shared state (ie: a dashboard).

I do know exactly what you are talking about. We do have some single pages that implement the boiler plate just so that they are consistent with the others.

</comment></comment></comment><comment><USER37> Regarding the Angular DI part: You don't need "provides" anymore on each component, afaik it's even deprecated. You just need to define it once on the module that defines the DI providers. And in the module of the component import that module. But your findings may already have been from some time ago where things were different in Angular land. That's for me the saddest story of Angular 2: Between alpha, beta, RC and final release dozens of things changed, which required me to constantly change my app. Now that it's stable I'm quite sophisticated with it.

<comment><USER17> > afaik it's even deprecated.

No, it's not. You use providers on a component when you want to have a new instance of that Service when a new Component instance of that type gets created. So you have complete control over the DI. More details here: [https://angular.io/docs/ts/latest/guide/dependency- injection...](https://angular.io/docs/ts/latest/guide/dependency- injection.html#!#injector-config)

</comment></comment><comment><USER23> I swear "React is just a library, not a framework" is the new "JavaScript is just a scripting language, not a programming language". The comments in this thread are a great example of this.

<comment><USER38> Well for me React being just a library is the very reason to use it. Frameworks are constraining, you code "inside" them and can't get out. Libraries are giving more freedom, you code "along" them. For example, I was really hating react-router and wrote my own, with proper state and url injection, in one or two sessions. I guess it would have been much harder if I was "inside" a framework.

</comment></comment><comment><USER39> I like the conclusion and it's a fair comparison. I, however, can't stand react with reasons I don't want to get into.

But I would kill to see a middle ground between react and angular.

</comment><comment><USER40> I would love to hear how people solve the snackbar problem in React. I don't even see how you would solve it with redux since that's just the state.

<comment><USER41> The snackbar problem is actually what redux is built to solve. You would "provide the toast()" function by having components dispatch a "toast" action. From there, your reducer would modify the snackbar state accordingly, e.g. by implementing a stack of toasts, and you would have a single global component render that state into popups.

<comment><USER16> Yeah. There's a dozen existing "notifications with Redux" libs already: [https://github.com/markerikson/redux-ecosystem- links/blob/ma...](https://github.com/markerikson/redux-ecosystem- links/blob/master/widgets.md#notifications) .

Behavior-wise, it basically just amounts to a pair of SHOW and CLOSE actions, possibly with the reducer tracking an array of open notification entries, and a component that maps over the array and shows an actual notification entry. I glanced at the ones in my list, saw the similarities, and just wrote my own.

</comment></comment></comment><comment><USER42> _> React-router has gone through a lot of version churn. I used the (at the time) still-in-beta v4 router. This is good because it's clearly a better solution than prior versions. It's bad because all the tutorials and most of the online documentation refer to the old versions. Also there were no typings for v4 (since fixed)._

And to think people complain about GTK changing too frequently...

</comment><comment><USER43> React is, of course, a work of a genius. But may I suggest another option in the same spirit, which is Riot.js? It is more elegant, compact and better syntactically polished, while retaining React's convenience and performance.

(I had approached React right when the infamous Babel5->Babel6 transition happened, and was seriously burned by it.)

<comment><USER44> I am using riot.js too and am pretty happy so far. Actually, I never tried react, but as riot is smaller, I like the tag syntax much better and I do not feel like I miss anything, I do not know why I should try it (anybody here prefers react over riot? why?).

Before riot, I tried Backbone, Ember and Angular. While Backbone did a fine job it didn't help to structure the app and everything had to be done manually.

Ember was too opinionated for me. Yes, they have some nice concepts and bring a lot of functionality right out of the box, but when you still have problems doing basic stuff after the third project, you know it's time to move on. The only thing I sometimes miss is ember-data.

Angular looked better to me, but they lost me with the Angular2 migration. I hate it when libs break backward-compatibility and in my eyes, there were enough good alternatives so that I did not have to risk facing the same story again with some future angular version.

The beauty in riot.js is that you can easily build small html components and stack them together afterward and reuse them later. It really feels like a lib which you can plug into something else. So I am able to develop an app using riot.js with framework7 and formatjs at the moment.

</comment></comment><comment><USER45> Nice comparison, please try Vuejs I have used angular 1 and react with redux in the past and Vue for me is so elegant and simple (it's also really fast), it has the component system of React and the template style of angular and you can create single file components .vue files that encapsulate html, js and css.

</comment><comment><USER46> I always hear Angular 2 ppl talk about how awesome it is, because of TypeScript and RxJS, as if they're the main good things about it.

If you really like these two things, try CycleJS. It's basically "Angular 2 the good parts"

<comment><USER47> Personally I don't see any appeal in either Typescript or RxJS.

</comment></comment><comment><USER48> "Some of us dynamically generate this for various reasons. You can just copy the important script tags into your html but it still seems weird and invasive."

You can use the ng eject command to add the webpack configuration to your project root and it'll add and print a set of npm commands too.

</comment><comment><USER49> I'm the project lead for Aurelia, so I'd like to take a minute to address a few of the points from the linked post. Jeff makes some valid points, for sure. However, there is also some inaccurate information and a healthy dose of subjectivity.

* Documentation - This one tends to be highly subjective. One's happiness with documentation is often highly dependent on learning style and what you are trying to do "in the moment". Jeff describes it as a "mixed bag". However, we've had plenty of people praise Aurelia's docs as amazing or even make statements such as "this is the way all documentation should be." Do we have room for improvement? Absolutely. In fact, we're working on a completely new documentation site right now. * TypeScript Support - We have a huge community of TypeScript developers who are quite happy with our support for the language. We provide d.ts files for everything. We also have a number of our libraries that are now completely written in TypeScript. This includes our new Webpack tooling, our Validation library, our UX Component library and more. We've actually worked directly with the TypeScript team to provide scenarios for them, which resulted in new features for TypeScript and submissions to ECMA for future versions of JavaScript. * Build System - Aurelia supports multiple options, including RequireJS, SystemJS, Dojo and Webpack. We have a very diversified community. Our CLI is designed for beginners who either are completely new to SPA frameworks or don't know how to use tools like Webpack. It's designed to get them up and running quickly and easily. It has been exteremely successful in that area and we've received a ton of praise for it. If you are a Webpack developer, I would expect you to use a Webpack setup instead though. We have a Skeleton for Webpack that's based on Webpack 1.x. However, we've got a completely new set of Webpack 2.x tooling. There have been blog posts about it, there's documentation, dedicated plugins, etc. It sounds like Jeff missed this somehow. Lots of people are using it though and loving it. We're doing some work now to broaden the availability of our new Webpack setup, so hopefully future devs won't have the same discovery problem that Jeff did. * Dependency Injection - This one is is pretty accurate. Our DI is extremely powerful and extensible, but we try to stay out of your way as much as possible. You can even use DI without decorators at all, in a pure ES2015 fashion, if you like. * Component Encapsulation - Here Jeff doesn't talk about the component model at all really. He's fixated on whether or not you can put a component in one file, something that tends to be a subjective requirement. That would be fine but he missed the point that you can include your JS and HTML in the same file with Aurelia as well, by using our @inlineView decorator. We've supported this for two years, but maybe we need to talk about it more. That said, we generally don't recommend this as the default practice, because we hold the opinion that it's better for developer/designer collaboration, parallel work, and sometimes even source control, if you put these things in seperate files. If you want to do it, you can though. The Aurelia strategy is to have a lite set of opinions but to always enable developers, which is why we support both paths. One other quick point here: Jeff calls out our component naming as "magic". However, our documentation very clearly points out that, if you don't provide an explicit component name, the convention is to use the export name. This is a fundamental convention in Aurelia that is well-documented. * Routing and Fetching - Here Jeff has a couple of questions about getting access to parameters in sub components and altering the way that routes generate titles. Those are all possible and would have been a good opportunity for Jeff to engage with our very helpful community. Jeff makes one cricirtism that is very valid though. Our documentation on routing is lacking in some big areas. I don't think there's any doubt about that. It's something we're working to remedy. Perhaps this is the central reason why he thinks Aurelia's docs are a "mixed bag"? * Ecosystem - This point really frustrated me. Our community is not tiny. There are tens of thousands of companies using Aurelia all over the world. There are tons of very large, well-known brands using Aurelia. Unfortunately, we can't share these names all the time. Please understand that Google and Facebook have considerable influence over other companies that we do not have. For example, if company X uses Angular or React, they want Google/Facebook to publish that information because the Google/Facebook brand is likely bigger than theirs and they want to ride on the coat tails of the larger, more influencial company. In our case, Aurelia as a project, is almost always smaller than the dozens of Fortunate 500 companies that are using it. So, they don't have any motiviation to share that information. Because the bureaucratic legal and marketing hoops are so numerous, we end up not being able to share many things publicly. * Ecosystem Part 2 - We have tons of 3rd party modules for Aurelia. Jeff states that there are no third-party component libraries for Aurelia. That's not correct. We've had public announcements about Telerik and Syncfusion component libraries. There's also a Materialize component library and at least one very large community-based component library in addition to the collection of individual components that people have built. Aurelia itself has an official component library. It's early, for that library, true. One thing I take away from this is that we need to focus on and "highlight" even more in our official docs and site these 3rd party components, because maybe people just don't know that they exist.

Now, we realize that Aurelia is far from perfect and that we always have plenty of work to do and things to improve on. I and my team of about 30 engineers have poured countless hours, worth millions of engineering dollars into Aurelia. We don't have the brand power of Google or Facebook. Who does? So, if you write this type of comparison post, please be careful to validate the information and maybe even reach out to the project contributors for feedback. Posts like this can cast all our work in an overly-negative light, particularly for those who haven't encountered Aurelia before and don't know better. We're all working for the same thing here and want to help each other and our businesses succeed. I always take feedback like this to heart and I and my team will continue to work hard to make Aurelia better every day. We invite everyone to join our community and contribute together to making Aurelia the best platform for modern web apps.

<comment><USER50> Thank you for Aurelia btw... I've used both Angular 2 and Aurelia professionally now and Aurelia is hands down a better framework and it's ease of use makes up for lack of documentation (which has improved a lot over the past few months and SO answers are usually answered pretty quickly). I've not used React and would like to stay away from it since I find the JSX file to be a horrid mixing of concerns.

</comment></comment><comment><USER51> Here is interesting comparison of frontend frameworks popularity in job offers:

[https://jobsquery.it/stats/frontend- frameworks/group](https://jobsquery.it/stats/frontend-frameworks/group)

</comment><comment><USER52> Urrgh, please stop using "opinionated" as a trendy, positive web development word. It's not even always certain that it is.

</comment><comment><USER53> first time I hear about Aurelia. I found Angular2 easier to start with, as I did not have to make decisions about what to use for router, DI, storage. With React (and React Native), there are many blanks to be filled, and hard to make a decision: Redux or Mobx?, which router?, who owns the style...

</comment><comment><USER54> What about Polymer? It would be also interesting to see it compared to Angular and React.

</comment><comment><USER55> Mithril, Mithril, Mithril

</comment><comment><USER56> And we can compare them on LibHunt by CodeQuality, Popularity & Dev Activity

React VS Angular [https://js.libhunt.com/project/react/vs/angular- js](https://js.libhunt.com/project/react/vs/angular-js)

React VS Aurelia [https://js.libhunt.com/project/react/vs/aurelia](https://js.libhunt.com/project/react/vs/aurelia)

Angular VS Aurelia [https://js.libhunt.com/project/angular- js/vs/aurelia](https://js.libhunt.com/project/angular-js/vs/aurelia)

BONUS Vue.js VS React [https://js.libhunt.com/project/vue/vs/react](https://js.libhunt.com/project/vue/vs/react)

It seems that Aurelia beats them all by Code Quality...

<comment><USER16> Rather depends on how they're measuring "code quality". A very brief search didn't turn up any specific description of their metric.

If it's simply, say, "number of issues", or even something like "average age of open issues", then an actively used lib like Angular or React is likely to have "less quality" simply because more people have been using it and filing issues over time.

<comment><USER57> lumnify describes the criteria[1] but is incredibly vague about it. unless/until they give detailed reports on each project explaining how they arrived at their conclusions I think it's fair to treat these grades as pulled out of thin air. and even then it would be of very little/probably still no value. every project is different and you need to evaluate your tooling based on the situation.

1\. [https://lumnify.com/grades/](https://lumnify.com/grades/)

<comment><USER56> They are not pulled out of thin air. You should contact them, and they will come with an answer. The algorithms have been tuned based on feedback from a number of Start Ups in Sydney.

<comment><USER57> they can open-source their methods/algorithms for public review if they want anyone to take their scores seriously.</comment></comment></comment></comment></comment>


Trying to find a list of blog sites - <AUTHOR>

Hi...
I'm trying to find out how to obtain a list of bloggers/blog sites for a survey we'd like to create. We're interested in talking to the "long tail" of the blog sites to try to get a feel for exactly what kinds of revenue is being generated for the sites for the various ad approaches.
We're willing to share the data we compile, if we can figure out how to obtain a list, of who/where these guys are. We figured we'd post here and maybe someone would have insight into this!
Thanks
-Bruce email@example.com <comment><USER3> Hopefully I have understood your request enough to give you a suggestion - <USER2> about something like Technorati? It provides a ranking system, You can look up blogs by category and maybe take the lower ranking ones to establish the "long tail"?

I hope that answers your question to some degree.

</comment><comment><USER4> I can't help you but I thought I'd offer some advice. Telling us you want a "list of bloggers/blog sites" is useless - Google can do that. Asking us a more useful, thought-out question would likely provide you w/ better results.

<comment><AUTHOR> ok.. i'll bite. how the heck can one find a list of sites via google??

but to your point, we're looking at creating a couple of blogs, but wanted to figure out what one can reasonably expect to earn from a blog. To that, we figured on creating a survey/questionaire that would (hopefully) be completed by various blog owners. Which would necessitate that we have a list of bolggers/blog sites to contact.

So, we're looking for a list of 400-500 bolg sites from the "long tail" that we might approach to complete a short survey.

We're more than willing to share results of the survey if we can obtain/access a list of the blog sites. And no, we're not trying to "sell" anything, just conduct some basic research.</comment></comment>


Nextdoor CEO Takes Blame for Deleting of Black Lives Matter Posts - <AUTHOR> https://www.npr.org/2020/07/01/886147665/it-s-our-fault-nextdoor-ceo-takes-blame-for-censorship-of-black-lives-matter-pos <comment><USER2> There is nothing wrong in deleting something related to the damaging Marxist operation/ BLM.

<comment><USER3> Define Marxist... I'm sure you wouldn't know what a Marxist is if Marx himself stood in front of you and read you Das Kapital in plain English. Problem with getting your education at Fox News University is that you become progressively more stupid.</comment></comment>


Florida Student Punished for Making Online Course Selection Easier - <AUTHOR> http://www.mashable.com/2012/08/07/student-course-selection/

<comment><USER2> This is terrible, he can change whatever he wants.</comment>


Facebook made its Android app crash to test user loyalty? - k-mcgrady http://www.theverge.com/2016/1/4/10708590/facebook-google-android-app-crash-tests <comment><AUTHOR> Sounds like the beginning of an urban legend. The truth of the matter is that Facebook engineering is getting bloated just like all other big companies and their apps crash not because they're testing user loyalty but because their code is just shitty.

<comment><USER2> Their app has been crashing constantly since day 1. On high speed wifi, my newsfeed regularly takes upwards of 10 seconds to load, and the iOS app crashes like a drunk. They do some truly hard things, and coupled with their "move fast and break things" ethos... well they end up with some stability issues. I'm not sure its an issue of bloat though.

<comment><USER3> Funny enough: the FB app never crashed on me, but Twitter does reproducibly crash after about 20 actions (Android).

Whatsapp however regularly loses its connection on Wifi (even when on battery, and wifi powersaving is disabled), and after 6 hours I see "oh, 20 new messages"...

Problem of scale is that neither of the three (or, actually two) companies has a public bug tracker where one could report bugs and see if anything happened with it. You basically feel like you're interacting with a fucking black box.

<comment><USER4> Sounds like you guys and your apps are a mess. Is this really where we wanted our mobile experience to go?

You know what rarely crashes for me? m.facebook.com on a web browser.

Facebook will never get installed on any device I own. Ever.

<comment><USER5> I'm not a Facebook user myself, but I've heard that the Facebook website can now send notifications through the browser, effectively eliminating the need of a bloated, buggy app.

<comment><USER6> It's true and I find that feature very annoying. Of course I can turn it off, but they shouldn't turn it on by default IMO.

</comment></comment></comment></comment></comment></comment><comment><USER7> Why "make it"? It crashes perfectly fine on its own.

<comment><USER8> Or...was it working as intended? _mind blown :)_

</comment></comment><comment><USER9> Please either point directly to the article that claims to have uncovered this (which is behind a paywall) or don't post anything.

Right now, there is zero evidence that any of this is real.

<comment><USER10> You can bypass the paywall by entering your email. Even in the full article they only mention a confidential source, which makes sense because even if it was real, it's very easy to cause a crash without leaving a trace in the app. For instance, the server might purposefully send a malformed response that causes the client to crash.

full article mirror: [https://i.imgur.com/umOEvs7.jpg](https://i.imgur.com/umOEvs7.jpg)

<comment><USER11> Did you use some tool or browser extension to generate this?

<comment><USER12> No the one you asked either, but I usually email firstname.lastname@example.com [1] from my Gmail account with the URL in the subject, and it saves the page as content AND as a long picture.

It would probably not work here since it would require to be logged in or something, in that case I guess OneNote Clipper [2] would do the trick.

[1][https://www.onenote.com/EmailToOneNote](https://www.onenote.com/EmailToOneNote)

[2][http://www.brucebnews.com/2015/03/onenote-clipper-is-the- bes...](http://www.brucebnews.com/2015/03/onenote-clipper-is-the-best-way-to- save-web-pages-and-onenote-keeps-getting-better/)

<comment><USER13> Sounds like Stallman's web program. [1]

> I usually fetch web pages from other sites by sending mail to a program (see > git://git.gnu.org/womb/hacks.git) that fetches them, much like wget, and > then mails them back to me. Then I look at them using a web browser, unless > it is easy to see the text in the HTML page directly.

[1] [https://stallman.org/stallman- computing.html](https://stallman.org/stallman-computing.html)

</comment></comment></comment></comment></comment><comment><USER14> Doesn't anyone else think it is odd that all these stories have started to appear in the last few day? It is almost like Google is planning something known within Facebook and Facebook is trying to send Google a message that they have a back up plan. Anytime I read articles with sources who are "off the record" it makes me wonder.

</comment><comment><USER15> And where is the reference / source of this claim?

<comment><USER16> linked in the article: [https://www.theinformation.com/facebooks-android- contingency...](https://www.theinformation.com/facebooks-android-contingency- planning)

<comment><USER17> The lede in that story doesn't even mention intentional crashes, anything not behind a paywall?

<comment><USER16> yes, here: [http://www.theverge.com/2016/1/4/10708590/facebook-google- an...](http://www.theverge.com/2016/1/4/10708590/facebook-google-android-app- crash-tests)

This is original reporting by The Information. They are the source of it, but they're behind a paywall so we get links to blog posts about it. If you want the source, you have to deal with a paywall.

</comment></comment></comment></comment><comment><USER18> >defaulted to the mobile browser version of the social network, rather than give up on Facebook entirely.

I'd rather use the mobile browser version of just about anyone's crappy app. There might be a handful of exceptions.

<comment><USER19> Tell that to clients. They're convinced that because they're in an app store that they're instamillionaires. My favorite one is house hunting on an app, a la Zillow.

The user numbers that a store reports are so pointless. It's a popularity contest. I wish that someone (anyone) would pull out some open analytics to show usage numbers instead.

At least it'd make my life easier.

</comment></comment><comment><USER20> I had a carrier locked phone that one day demanded that I log into Facebook. It would repeatedly launch and I ended up having to flash the phone. Drove me nuts.

</comment><comment><USER21> In my non-technical circle of friends most of us have recently given up and uninstalled the Facebook app because of resource usage and undesired notifications rather than crashes. I don't care if the app crashes every now and then when I use it. I hate when it sends me notifications of people I've met once and runs constantly in the background to do so.

</comment><comment><USER22> Who gives a shit. They're free to degrade its performance all they like in order to test it. Its not as if Facebook has some kind of SLA, its a free service that nobody is obligated to use.

<comment><USER23> They have a lot of influence on standards of behavior for other web app companies, not to mention expectations of users.

They are relevant, like an 800 pound gorilla.

</comment></comment><comment><USER24> So they want us to believe that they are malicious, not incompetent?

Weird people...

</comment><comment><USER25> Well, not sure if it is a coincidence. Facebook app on my iphone crashed several times a couple of days ago.

</comment><comment><USER26> Yeah me too, whenever I have a bug it's just my way of testing user loyalty.

</comment><comment><USER27> "this person said"

Absolutely zero source or actual citation from an actual person.

</comment><comment><USER28> "Facebook, despite being the biggest app developer on Android, presents a growing threat to Google."

Shouldn't that be Facebook is the biggest developer of Facebook apps on Android?

Was this article written at Facebook HQ?

<comment><USER29> I think the author wanted to say biggest by number of downloads or by popularity

</comment></comment><comment><USER30> I deleted it.

</comment><comment><USER31> Very sneaky but clever.

</comment><comment><USER32> " _I just don't feel like our users_ love _us enough._ "

[http://www.smbc-comics.com/index.php?id=3970](http://www.smbc- comics.com/index.php?id=3970)

<comment><USER33> Everyone knows there's a relevant XKCD for everything, but when SMBC starts to seriously predict the future, it means we live in _really weird_ times.</comment></comment>


Hacking First Meetings For Startups - <AUTHOR> http://www.startupmoon.com/hacking-first-meetings-for-startups/

<comment><USER2> As good as his sounds, it might put you in a serious disadvantage during negotiations. Only use this if you are dealing with a very specific personality type known as a nurturer (someone who values personl connections and nurtures them from the start). Otherwise you might not be tken seriously.

<comment><AUTHOR> Interesting - My understanding of these was that by using this kind of open communication you'll be able to get(most) people to open up and tell you more about what they do, which might help as you as you make your way into an organization. When/how do you think this can put you in bad spot during negotiations?

<comment><USER2> It will mostly get you deceived. People are rarely open in such way, unless they are of a certain personality type. Being open like this is really the worst thing you can do in the rel business world. Now, I'm not saying you shoe not be honest, but you should definitely plan ahead nd strategize before any meeting.

Though there is one shortcut to getting people to opening their mouths ( and thus give you an advamtge). Find a pain or a pleasure. They will regularly not shut up. But be very careful. Asking directly is not ideal. Make some research beforehand.

</comment></comment></comment><comment><USER3> It appears we sometimes focus so hard on getting the answers we need, that we forget to take that one step back and make the conversation more pleasant for both parties -- something that would in turn yield better results and better relationships.</comment>


Chunk Host Offering Free Hosting - <AUTHOR> https://www.chunkhost.com/

<comment><USER2> Seems like a pretty deceptive company. They display the following during the signup process:

"We'll disable signups that don't seem to be a real person, have few friends, or are obviously underage"

I didn't realize there was a minimum age to use a VPS. It also seems that unpopular people with too few friends don't qualify as VPS users.

After I signed up and they had my info (public profile, friends list), I received:

"Sadly, we are at capacity at the moment, but we're fixing that ASAP!"

</comment><comment><USER3> On the one hand, it seems strange that a hosting provider would be giving out free VPS accounts. This seems like it would be the last act of a dying hosting provider.

On the other hand, this is probably not much different than what Heroku gives away. In fact, Heroku probably gives away a lot more resources (considering that AFAIK you can create as many free tier apps as you like.)

Perhaps this will be the opening shot in a new trend which started with the PAAS providers. Provide free low tier space and make money off the bigger fish.

Personally, I would rather not share my space with freeloaders unless that space is tightly restricted. If the providers are being squeezed on their margins from competition, then I would rather those low margins be spread equally through all plans with no free tier (which I suppose is what Amazon does, they are regularly dropping their prices but nothing is free except for the trial.)

Free hosting isn't enough to move me away from DigitalOcean, especially given the SSD storage.

<comment><USER4> That was my initial reaction; free hosting to get switchers as a last ditch effort? No thanks, I'd rather pay a small sum to support a good product.

I had tried these guys last year when they were doing a different 'free' promo. For whatever reason I was unimpressed and had never gone back after the one instance. Not that they're bad, but I don't remember them being memorable over the well-knowns of the VPS market.

</comment></comment><comment><USER5> Hmm. Here's what they say about the free tier:

      Free as long as you use it!

      If your chunk is inactive for a while we'll hibernate
      it and keep it in case you come back!

I wonder what constitues "inactive". No SSH login? No network traffic? It doesn't say in the FAQ.

Still, very interesting...

</comment><comment><USER6> I remember some time ago when chunk host first launched. They advertised that the service was "free during beta", when what they really meant was "free beta test" (more accurately: "free 30 day trial"). Since that blatant act of false advertisement I've never spoken well of this company to people looking for hosting. I don't expect they'll be any less scuzzy with this current deal.

<comment><USER7> Yep, it feel scuzzy to me when they wait till after I've authorized their facebook app to have access to my friend list and profile before letting me know that the deal is now off.

Thanks for signing up!

Sadly, we are at capacity at the moment, but we're fixing that ASAP!

Your pal, ChunkHost

</comment></comment><comment><USER8> Also requires a Facebook account, so I guess it sucks to be me.

<comment><USER9> I hear you.

</comment></comment><comment><USER10> I frequently get my chunk disabled because "inactive".

The I/O is complete garbage. `ls` frequently takes a long time... I've seen I/Os ranging from 100kb/s to 5MB/s

</comment><comment><USER11> I can't even sign up. Just get "Facebook returned an error" and shuts me off.

</comment><comment><USER12> Is the signup failing with "Facebook returned an error:" for anyone else?

</comment><comment><USER13> Thanks everyone! The clear signal is: Run for the hills!

</comment><comment><USER14> Their IPv6 support looks iffy: <http://wiki.chunkhost.com/ipv6></comment>


Don't post your kid online - <AUTHOR> https://thenextweb.com/lifehacks/2018/11/12/dont-post-your-kid-online/ <comment><USER2> Why not host your photos on your own site; watermark them and not allow ads? Don't use Facebook or other platforms except to direct people to your own. I know hosting is hard, but you can pay several services that do most of the work for you.

You can still have a presence online, but have it be a website, not a big ole social network.</comment>


Samuel Colt's "YC app" for the Summer 1851 batch - <AUTHOR> http://www.hscott.net/ycapp.html? <comment><USER2> I don't see this being a viable product.

1) For a machine shop owner, you can already build such a "multi-shot gun" yourself quite trivially. I have a setup in my barn where I can spot-weld seven rifles together along the length of the barrel. I then use a bunch of loops of baling wire that run from the triggers to the end of the stock so that I can fire the correct rifle without any awkwardness.

I haven't tried this with pistols but the general approach should be the same.

2) My system also has the benefit of me not being tied to one company's proprietary standard of "interchangeable" parts. If you buy a Colt, you're stuck buying Colt parts forever. With my system, I can weld together any guns I want.

3) It does not seem very "viral".

</comment><comment><USER3> Sounds neat, but..

\- How are you going to scale production to meet demands? Does not look like you could reach the kind of growth YC wants. \- Who is this guy and why should I trust his guns? How do I tell how many bullets I have left? \- Seems like rearming would be a pain! Reloading just one chamber is already difficult.

<comment><USER4> "I worry, I worry."

</comment></comment><comment><USER5> That's a well-written app. It clearly explains what they're doing, why it's important, and why they're the right team to execute on it.

<comment><USER6> So is it the first "killer app"?

I've previously heard something like:

       God made men
       Sam Colt made them equal

But Colt itself says[1]:

       Abe Lincoln may have freed all men,
       but Sam Colt made them equal

[1] [http://www.colt.com/Company/History.aspx](http://www.colt.com/Company/History.aspx)

</comment></comment><comment><USER7> Seems like the barrel is a single point of failure. How is this better than simply carrying more than one pistol? Allowing complete fail-over in case of a malfunction.

Pretty design, but the proprietary projectiles breaks compatibility with existing arms.

<comment><USER8> How do these guys think they're going to avoid gang-firing the whole cylinder and blowing up the pistol?

</comment></comment><comment><USER9> Pretty funny, but I've been working on this post about the same thing for the Wright Brothers: [https://news.ycombinator.com/item?id=9291316](https://news.ycombinator.com/item?id=9291316). Great minds think alike. Maybe if we could put some guns on a plane...

<comment><USER10> Good read. BTW, the HN link says 1802 instead of 1902.

<comment><USER9> Argh. I wish I could fix it. Thanks for the heads up, though.

</comment></comment></comment><comment><USER11> Rejected, doesn't know the market:

        It's much safer and more reliable than flintlock, which is what people are using now.

In the enterprise of war, we use percussion caps these days.

<comment><USER12> Percussion caps were only invented in the early 1800s and weren't widespread until the 1830's, so this is not as wrong as it sounds. Flintlocks were still widespread when the Colt revolver was invented.

<comment><USER11> Fair enough, but the military (an similar orgs, e.g. texas rangers) were using percussion mostly by then right? The big customers they list are the military.

<comment><USER13> Percussion cap revolvers are very prone to dangerous cross firing in the cylinder. Mr. Colt should have emphasized that.

</comment></comment></comment></comment><comment><USER14> Funny idea. Are there more examples of fictional YC applications of historical or modern companies?

<comment><USER15> I think it would be hilarious to see fictional "failed" historic YC apps, especially those that made it big in their time.

<comment><USER16> Or even better, real applications from ultimately successful companies that failed to get into YC.

<comment><USER17> Buffer's app is one example, but I'd like to see others. [https://open.bufferapp.com/buffers-y-combinator- application/](https://open.bufferapp.com/buffers-y-combinator-application/)

</comment></comment></comment></comment><comment><USER10> Someone just showed us an idea like this right before you guys. We don't like it. What else do you have?

</comment><comment><USER18> Rejected. Won't move to SV. Takes to long.

Now if someone would only hack the isthmus of Panama...Hmmm

</comment><comment><USER19> I can't believe they didn't mention their big US navy contract! Cartridged rounds are a big plus at sea!

<comment><USER8> Colt (and Remington, and other early revolvers) had a muzzle-loaded, cap-lock design for guns up until after the US Civil War, IIRC. (Also, IIRC, I don't think paper cartridges were ever a big thing for revolvers. Colt's early guns removed the cylinder to reload, which meant you could theoretically carry spare loaded cylinders; Remington guns had a built-in loading lever.) In fact,

" _In 1852 an employee of Colt 's, Rollin White, came up with the idea of having the revolver cylinder bored through to accept metallic cartridges. He took this idea to Colt who flatly rejected it and ended up firing White within a few years.[18] Colt historian RL Wilson has described this as the major blunder of Sam Colt's professional life.[19] Rollin White left Colt's in December 1854 and registered a patent on April 3, 1855 in Hartford, Connecticut, as patent number 12,648: Improvement in Repeating Fire-arms.[20] On November 17, 1856 White signed an agreement with Smith & Wesson for the exclusive use of his patent. The contract stipulated that White would be paid 25 cents for every revolver, but that it was up to him to defend his patent against infringement as opposed to Smith & Wesson.[21]_"

...(from Wikipedia) with the result that patent licensing meant that Colt couldn't make or convert metallic cartridge guns until well after the Civil War (IIRC).

</comment></comment><comment><USER20> Wow, really neat and well executed.

I was thinking of doing an similar product but couldn't get time for it.. All the best for you guys.

BTW, Are you planning for global reach or targeting only local?

</comment><comment><USER21> I opened the video link in the background while I read the application. For the first two minutes I thought the drive in my macbook pro was going bad.

</comment><comment><USER22> I think they have done a great job doing things that don'f scale. Also they have a lot of paying customers and traction.

But I am worried that this might be a solo founder type team. We invest in teams, not just products. You'd be surprised how many times an idea changes midway through the project, and you will need each other to keep going.

</comment><comment><USER19> Compared this to apps friends have shown me, this is really concise.

</comment><comment><USER23> So would they get in?

<comment><USER24> Would YC fund weapons?

<comment><USER25> Only if the company is really killing it.

</comment></comment></comment><comment><USER26> tough competition this batch

</comment><comment><USER27> Ah, they have revenue and users!? This sounds like a feasible business model. Rejected.

</comment><comment><USER28> Hilarious!!! I did not like the application. I am glad it was a joke.</comment>


Ask HN: How best to cook a steak? - <AUTHOR>

I know there's lots of contention in the startup community on this issue so I'm going to ask it straight:
What's the best way to cook a steak ?
I have 30 minutes to make this happen. The steak is a small sirloin medallion (x2).
[edit: I have slightly longer now as my wife has just stepped into the bath ! Thanks for all the suggestions - will keep you posted]
[edit 2: Seasoning - http://twitter.com/whyleyc/status/312662132124692480/photo/1] <comment><USER2> Freeze it and then sear it on extreamly hot skillet frozen, then put the skillet in an over on 200F until it is done to your liking.

[http://www.nytimes.com/2012/01/18/dining/seared-frozen- rib-s...](http://www.nytimes.com/2012/01/18/dining/seared-frozen-rib-steaks- recipe.html?_r=0)

They are fairly expensive as far as cookbooks go, but the book collection Modernist Cuisine is the state of the art. The recipe above is an adaptation of their technique. You will be hard pressed to create a better steak without years of practice in various techniques.

There is another technique where you Sous vide the steak to temperature and hold it there for some time, and then put a sear on it, but it takes Sous vide equipment. Though it produces an amazing steak.

<comment><USER3> You don't necessarily need sous-vide equipment to do it. Here are some people that did it using preheated water and an insulated cooler:

[http://www.seriouseats.com/2010/04/the-food-lab-perfect- rack...](http://www.seriouseats.com/2010/04/the-food-lab-perfect-rack-of- lamb.html)

While real sous-vide hardware will get the temperature precise enough to do exotic things with certain ingredients, a simple water bath in a cooler like this will get you 99% of the way when it comes to a steak or lamb chop.

<comment><USER2> I agree that you can accomplish very similar results with water, but traditional sous-vide uses an oil based bath held to temperature. For some reason oil seems to hold heat more stable and transfer heat more evenly but water is certainly better than say an oven at evenly distributing heat.

<comment><USER3> Correct. But I get the impression that modern sous-vide techniques are about precise temperature control, not the method used to get there.

Everyone uses immersion in oil to cook these days. It's called deep-frying.

</comment></comment></comment></comment><comment><USER4> Sure, why not.

Dry cast iron skillet, put in oven, heat to 500*F. Prep steak with olive oil and salt and pepper.

Take skillet out of oven, put on stove at high. Cook 30 seconds on each side. (total cook time on range: 1 minute)

Back in oven, 2 minutes each side. (total cook time in oven : 4 minutes)

Let rest 3 minutes.

<comment><USER5> There is only one important step missing from this. Let the steak sit out to become room temp. Try it just once and you will never look back.

</comment></comment><comment><USER6> Sprinkle liberally with salt and pepper, or Johnny Salt, or what have you;

Turn a small camping grill to HIGH for a few minutes to get really freaking hot;

Throw it on with a pat of butter on top with the lid closed; flip it once and put more butter on top. Light char on the outside, purple in the middle.

Ingest with a fine potable from North Coast Brewery or whatever blended scotch is at hand.

<comment><USER7> This just made hungry. My god, next time I visit LA, I'm emailing you. (:

</comment></comment><comment><USER8> I recently followed this video to cook a steak, which goes against the flip once philosophy. One of the best steaks I've ever had: <http://www.youtube.com/watch?v=RW3ay3k0lek>

</comment><comment> o0-0o -= Dean Martin's Steak Recipe =-

Martin Steaks:

2 prime usda new york strip steaks 2 oz bourbon, chilled

Preheat a heavy frying pan and sprinkle bottom lightly with table salt. Grill over medium-high heat about 6 minutes on each side.

Pour chilled bourbon in chilled shot glass and serve meat and bourbon on a TV tray.

-= Frank Sinatra's Steak Recipe =-

Sinatra Steaks:

Call for Deano. Tell him to make you a fu*kin' steak. Drink his bourbon.

</comment><comment><AUTHOR> Thanks for all the tips guys - I went for a blend of approaches and it paid off - My wife rated it the 2nd best steak of her life - a triumph !

I found this useful: [http://www.guardian.co.uk/lifeandstyle/wordofmouth/2012/oct/...](http://www.guardian.co.uk/lifeandstyle/wordofmouth/2012/oct/25/how- to-cook-the-perfect-steak)

</comment><comment><USER9> The steaks have to be at room temperature. Pat them dry first. Put them on a plate. Sprinkle with salt. Get a clove of garlic ready in a press. Keep the butter nearby. Use a frying pan on Medium High to High heat that has been oiled (Grapeseed Oil or other oil that is safe at high heat). When it gets hot put in some butter, stir that around and then put in the steaks. Cook them on both sides for a couple of minutes. You can turn them more than once if you want. While they are cooking squeeze in the garlic and add more butter if you want/need it. Brown the edges if you want only just before you are ready to take them out of the pan. THEN put them on a plate or cutting board and let them stand for a few minutes (while you plate up whatever else you cooked with them). They're ready!

</comment><comment><USER10> I think the cut of steak is equally as important. I personally prefer a ribeye or filet over a new york or top.

My cooking style is right inline with dorianj (cast iron skillet + oven). I'd add that I like the steak to sit out at room temperature for 30-60 minutes and I pat it dry on the outside.

I'll put a small bit of butter or blue cheese on a filet while it's resting (rib eye doesn't need it).

Also, try dry aging your steak in the fridge. I don't usually remember to do this but it does work: [http://lifehacker.com/5865849/dry+age-steak-at-home- for-stea...](http://lifehacker.com/5865849/dry+age-steak-at-home-for- steakhouse+quality-meat)

</comment><comment><USER11> Dry brine: coat heavily with kosher salt and let sit in the fridge for a couple of hours, then wash off the salt thoroughly. Then sear quickly in a pan for 30-60 seconds, and finish in the oven to medium rare.

</comment><comment><USER12> Here is the definitive thread on how to cook a steak. On a poker forum no less:

[http://forumserver.twoplustwo.com/34/other-other- topics/cook...](http://forumserver.twoplustwo.com/34/other-other- topics/cooking-good-steak-836907/)

</comment><comment><USER13> How does this fly as an acceptable question to ask - but I cannot get feedback on my project, despite being a member for over 700 days...? I get the "your account is too new to submit" message.

Thanks in advance for advice.

</comment><comment><USER14> High heat for a few seconds, low for a few minutes.</comment>