This is cool and nerdy and all, but how this can possibly appeal broadly enough to hit HN front page is beyond my understanding - as is 99% of the article. Sorry, had to say it, feel free to downvote.
Around age 7 my daughter showed ocd like behavior (incessant scratching her arms) when she realized loosing connection during chrome casting meant the device kept playing. We had to unplug the chromecast device and inspect it, lying there dead and silent on the table, to settle her down. Same thing when our pc was updating, saying “please do turn off computer” and then _proceeding to reboot on its own_ at end of update. She wouldn’t enter the living room if google home was plugged in, and we would have to convince her it was OK google was listening (!…). as a toddler she would shake from fear if curtains were gently blowing - we figured she thought someone was standing there and tried to inspect it together to no avail. only recently we understood she in fact feared the house would blow away.
Equal parts worried and proud of my little tin foil hat in the making :-).
Three advantages:
First, studies show people like to say no more than yes. This fits a no, perfect for the knee-jerk denial, but most would follow up with a reason. As the reason is formulated, one may realise the initial assumption is wrong. However, at this point the person is discussing with himself. This is exactly what you want: The asker is out of the picture; the parades are down.
Second, an answer in the negative does not reflect poorly on the asker, as the question does not speak to preference. He may already be inclined towards a no, but just want the reason for X not being the better choice. Hence, less chance for a follow-up justification leading to a discussion.
Third, it merely establishes if X is feasible. Higher chance of finding common ground when discussing feasibility without preference.
Lastly, it doesn't get much shorter than this. Less words is less skin in the game.
Did you consider the point about code being defined only at build-time, not being available for inspection by the developer? That sets it apart from most auto-generating code scenarios I've seen.
- you're likely better at KISS than most.
- 90% of web development is repetitious. if you weren't stressed you can do it.
- cut down work hours
- stay happy. you're not sick. your family is not sick.
- learn to play an instrument. seriously, this is a great way to enhance mental performance.
- everyone feels the same to a degree.
TL;DR: "react native sucks because javascript". So much else I wanted to know from an experienced iOS dev, like:
- How is perf in a large app with lots of network IO?
- How does animation/ transition fit with reacts render loop and how does it perform, especially during network IO?
- How much is lost from not being able to do multithreading?
- How hard is it to achieve the last 20% fine tuning of feel and perf?
- How much flux is the community driven deps typically causing?
- Is memory management an issue? GC stutters, leaks?
- Do some UI parts simply not scale well enough, requiring native code instead? e.g. infinite scrolling, charts, complex transitions?
- How mature is the tool chain? Build time?
- Frequency of breaking changes from core? from common deps? Cost of staying up to date?
Developing in JS, with all the pros/cons of the JS language, is the very premise of the react native deal. Most issues raised would apply just as well to any web app.
I think it solves a problem we have (if my understanding of your product is correct): We should focus less on the future and more on the present and past. That will save time and make for better progress evaluation.
In our team, we're managing upcoming work by epics, features, user stories and tasks (TFS style), all ahead of time. For the latter two, ages are spent estimating, in the process having feelings about risks. We're left with a bunch of tasks that only partially describe what we eventually realize needs to be done, leading us to choose between sticking to the tasks, thus producing a nice burndown chart, or doing what's best for the project.
For our team, the devs just want to know if we are spending our time in the best way possible:
1) What are we going to focus on today? Not completing, just focus on. That's mostly enough to align efforts.
2) What did we focus on yesterday, and can we evaluate progress? Steady? Slow? Stuck?
3) What did we actually end up focusing during the past week? Did we side track often or have to change direction?
However, without the future aspect, management probably wont bite, making this a tough sell. So maybe consider something that marries the two: Some high level future planning, breaking work down to epics and features only, and some focus tracking for daily alignment and performance evaluation.
You missed Bamse ("Teddy"): A self-absorbed egocentric narcissist, taking advantage of his naive, little-minded friend Kylling ("chicken"), episode after episode with zero negative impact. After +20 years he's now joined by Bruno, also a teddy bear, sharing similar personal flaws except with much refined insults bordering on psychopathic abuse, bullying kids instead of chickens, believing firmly that the world exists solely to please him in every which way.
However, mostly you may have missed the subtle, educational point (yes, there is one) underpinning these characters: Critical thinking. Is it right to behave like this, even if there is no negative consequence (as is often the case in real life)? Do you emphasize with someone taking advantage of their friends? In Denmark, we have this crazy idea that kids are interested in distinguishing right from wrong, even when the answer isn't spoon-fed by a morally correct television character - and maybe exactly because it isn't.
The kids don't like Ramasjang because it's a training ground for inspiring film makers. The like it because naughty is fun. And, if done right, it just may induce some critical thinking. It'll take more than a few days of watching, but just like the kids, you'll see the point :-)
Best regards from a grown-up, bottle-fed on Bamse, somewhat certain of right from wrong.
true, but to be fair, you'd probably also want to introduce variables like $addPhotoBtn, $tweetBtn, $textLengthLbl, etc, to avoid css queries on every keyboard change. That would add to solution length and also introduce a bind-step to avoid stale variables after a dom change.
Also, there's the authors very well-placed point that adding a new feature may lead to css query refactoring, eg. when $("textarea") doesn't cut it. I find html refactorings to be nb 1 cause for breaking progressively enhanced solutions like this one, probably bc I suck at naming elements.
Lastly, it should be noted that this refactored solution does not contain all the features of the final react solution.
"if A card (as in, at least one) shows an even number on one face, then its opposite face is blue".
This was my first interpretation, based on "deceptively easy" and "not turning any unnecessary cards". Which sentence did I miss that rules out this interpretation?