n8agrin

From there it could be compiled to targets declarative or procedural (eg to generate VegaLite specs, echart specs or Observable Plot configs in JS).

How have you been thinking about this problem space?

While I deserve no credit for its current success, it's been used by millions to:

* catalogue millions of plants and animals around the world

* tagged image data has become critical for computer vision training models

* map species range and impact of various natural changes to biodiversity, with data cited in scientific journals

* new species have been discovered through the app

previous HN thread - https://news.ycombinator.com/item?id=22442479

When we started, our goal was to encourage people to go outside and engage with the world around them. We dreamt that the data gathered by the community would be used in scientific research, but weren't confident it would ever reach enough of a critical mass. It has! More surprisingly, we had no idea how important iNat's image dataset would become for computer vision research.

Again, so proud of the folks who have helped to make iNaturalist thrive and so glad it still exists in the world.

"Every person who, under color of any statute, ordinance, regulation, custom, or usage, of any State or Territory or the District of Columbia, subjects, or causes to be subjected, any citizen of the United States or other person within the jurisdiction thereof to the deprivation of any rights, privileges, or immunities secured by the Constitution and laws, shall be liable to the party injured in an action at law, suit in equity, or other proper proceeding for redress, except that in any action brought against a judicial officer for an act or omission taken in such officer’s judicial capacity, injunctive relief shall not be granted unless a declaratory decree was violated or declaratory relief was unavailable. For the purposes of this section, any Act of Congress applicable exclusively to the District of Columbia shall be considered to be a statute of the District of Columbia."

More here: http://en.wikipedia.org/wiki/Enforcement_Act_of_1871_(third_...

I'm always shocked that this hasn't happened faster. I've expected Dropbox, Amazon, Google and Apple to move into this space more aggressively, but at best they've all only just scraped the surface of what's possible.

What you're suggesting is usually called progressive enhancement. Yeah it's great, but sadly when you are using a system like Spine, Backbone or Ember, it's not just a matter of "endless Firebug sessions" to resolve the initial bootstrap problem.

No one claims that this is not possible, nor is anyone "crying foul". On the contrary I know first hand how much of this work was done at Twitter and how difficult it is. But as you stand by your petulant claim that "twitter.com is slow because twitter is incompetent or doesn't care about their product." I stand by mine, that there are tradeoffs when embracing one style of development over another.

Feel free to disagree with me but back it up with experience, not false assumptions, blanket statements and the denigration of many good people.

Let's take your solution: it's really difficult to build a development environment that allows a large team to work efficiently which is not based on having essentially a single bootstrap file when deployed in production. When you break apart your files into smaller chunks you are asking your developers to understand the intricacies of asynchronous loading of each file and impose dependency management on everyone. This is a huge problem at Twitter's scale.

FWIW, Twitter did break apart their files into smaller chunks pretty effectively using the Loadrunner project (https://github.com/danwrong/loadrunner).

That's not to say that Rails doesn't make a great API and that Alex doesn't have a point. There certainly is a place for frontend applications out there built on frameworks like Spine, Backbone or Ember (all great projects). Those types of applications have their advantages in some cases. But, it's prudent to be pragmatic and to recognize that the times where you truly need to build a client driven application are few and for the other times Rails is still great at serving up HTML.