Reading that article reminds me of the Montessori system, which did get developed using scientific methodology.
They seem to differ in a few aspects: Montessori is an early education system, and it does aim to develop specific skills (fine/motor and sensorial skills, and eventually reading and writing). But the two seem similar in that they empower the children to choose their own activities.
Rather than dictating specific activities following a schedule, Montessori structures learning by providing a large variety of "materials" (basically mini-puzzles that challenge a specific sensorial/motor skill with increasing levels of difficulty), and letting children choose their own activities. The teacher takes a passive observer role, merely demonstrating how activities are done (e.g. sorting sticks in order of length)
The rationale is that children are naturally curious and can frequently get into the "flow" with a puzzle.
Wikipedia has this to say about studies:
"A 2005 study and associated review concluded that Montessori education results in comparable (but not higher) academic achievement to traditional approaches. The review also concluded that studies have found no detectable differences in personality as a result of attending Montessori schools. The study of the public high school in the Milwaukee Public Schools found that Montessori students, aged 3–11, outperformed control groups on maths and science, and that Montessori had some of the largest positive effects on achievement of all programs evaluated. Another study that compared the academic achievement of 543 urban 4th- (n=291) and 8th- (n=252) grade students who attended Montessori or traditional education programs failed to support the hypothesis that enrollment in a Montessori school was associated with higher academic achievement."
I'd be curious to see more studies w/ montessori+sudbury education compared to traditional (especially considering many "montessori" schools nowadays have mixed methodologies that differ from the original methodology developed by Maria Montessori)
If you're going to rewrite it anyways, then why not just pick a random framework? "No framework" is still a set of trade-offs, and for better or for worse, most teams aren't made of super star devs. A lot of them appreciate the hand-holding through the where-to-put-what drudge at the beginning of a project and the presence of a community to ask questions.
1.) Just by choosing to use a framework, you incur costs: download time, initialization time, complexity & bug surface area, etc. You should make sure that you gain benefits commensurate with those costs. If you start by picking a random framework, then a.) how can you measure what the costs were? and b.) how do you know what sort of benefits would be most useful to you?
3.) Frameworks make certain tasks easy at the expense of making other tasks hard. If you start with a random framework, you will be incentivized to do things in the same way that everyone else who uses that framework is. That's why almost every web 2.0 startup started from around 2007-2010 looks like a frontend over a database. Looking like everyone else is a recipe for failure in business.
4.) The framework authors are all subject to the constraints of the browser; however, browser vendors (and people who program directly to web APIs) are not subject to the constraints of the framework. The set of programs that you can write efficiently without a framework is a strict superset of the set that you can write efficiently with one.
5.) It's easier to add code than to remove it. If you start with no framework and then decide that you need one, you've written only the code that you actually did need for your problem. If you start with a random framework and then decide it's not appropriate, you need to backtrack and identify what you were actually trying to accomplish before you shoehorned it into the framework.
1) this line of argumentation seems like selective reasoning. For example, one could say, ok I need ajax. Let's use a `fetch` polyfill. Wait, you can't abort the request with it? Fine, XMLHttpRequest then. How do I take my object and serialize it to a querystring again? Oh, I need to change a HTTP header to make my server accept the request body as JSON? Should I just use jQuery? It's too overkill. What about Reqwest? Does it do what I need? Is it maintained? etc etc etc. Point is: you don't know what kind of costs you're going to incur, regardless of whether you're using a framework or not.
2) going off 1), one could come to the (obviously ridiculous) idea that AJAX is really hard. Or that frontend build systems are not worth the trouble (I actually see this "myth" in the wild, and people wasting time due to it). 60fps on mobile is really not a "competitive advantage", even if you're going into the hyper-saturated gaming market (and in that case, you really ought to be writing ObjC/Java if you care about speed at all). Competitive advantage is about creativity and relentlessly exploiting opportunities, it's rarely ever the case where an obscure piece of software trivia will make a huge difference.
3) frameworks exist on a spectrum: if your argument was true, one could just pick an obscure framework. But honestly, It strikes me as wishful thinking to suggest that framework choice is the primary driving factor for a product (that's why the role of product managers exist)
4) there's a very real and recognized constraint that affects all low level systems compared to higher-level abstractions: complexity. jQuery is a DSL for avoiding 10000+ LOC DOM API code. Virtual DOM (or any "retained mode" templating system) help avoid 10000+ LOC jQuery spaghetti. Component systems let you create more DSLs, etc, etc.
5) it is easier to add code than to remove it, and that's precisely why most systems in the wild have technical debt: organic growth. When you start from scratch, in my experience (especially w/ a team over a period of time), it can get pretty hard to untangle the various subsystem out of an organically grown codebase. We had this issue in my previous company: there was a monolythic architecture for a mission critical system, and the 10 year old Session class was essentially impossible to replace without breaking everything. Speaking from experience, frameworks actually make it easier to bail out because there are only so many idioms you need to expect, and code is more-or-less organized even if it is a shitstorm by any other metric. With non-framework code, you get to spend a lot of time evaluating for the umpteenth time why exactly foo is seemingly replaceable, but actually not without breaking bar, baz and quux.
Is it my impression or is Paul on some sort of a crusade to downplay the dev ergonomics of React and try to convince people that it's "slow"?
TodoMVC benchmarks have been done before: https://github.com/pygy/todomvc-perf-comparison . So sure, there's room for performance improvements in mainstream frameworks, and React is not the fastest thing in the universe, but come on. Maintaining a large project in vanilla js is largely equivalent to writing code in assembler when there are good C compilers: it's doable, and required in a handful of situations, but not really wise for 99% of real world projects.
Re: Tom's response: Something that he didn't mention (which is not surprising since he's an Ember dev) is that frameworks do sometimes detract from end user experience by imposing "opinionated" complexity and assumptions that might prevent devs from doing certain specific things and settling with suboptimal UX - the old adage of "if you want to deviate from the holy way(tm) you're on your own"
I'm kinda in the middle of the two opinions: it's definitely important to have access to the "metal" (both in terms of actually being able to code against low level APIs, and in terms of the amount of effort required to wade through framework abstractions in order to get there), but even using vanilla js, a complex app does need a "framework" (in the sense of having rules for where things should be and how they should interact with one another, and in the sense that any non-trivial app will have "library-level" plumbing). So, why not meet in the middle and use a lightweight framework that does 95% of things well enough to actually be used in non-trivial mobile apps but that doesn't have high enough byte count to be bloated?
It's not that they are preferable, it's just that these verbs were invented for a reason, and people often ignore that because they didn't RTFM.
POST can be thought of as pasting a file into a folder from your clipboard, without necessarily knowing what its filename is. It oughta tell you the filename after you paste so you can retrieve it later. Typically, in a REST setting, you'd POST a thing to a collection (e.g. POST /api/v1/things)
PUT can be thought of as piping stuff to a file, when you know the filename ahead of time. It completely overwrites any existing data in that file. You'd PUT to the path where the resource should exist (e.g. PUT /api/v1/things/1)
PATCH can be thought of a version control diff. It's actually really powerful, but unfortunately, there's no widespread format to express diffs of deep structural data often seen in REST APIs, so most people avoid it. A PATCH request should contain instructions on how to add and remove sub-fields from a resource. It can be used on collections to batch-add/remove items, and it can be used in single resources to modify them without overwriting other existing fields (or even do all of those with a single request)
Thanks for your input! Some button don't do anything right now because there's only one entry for the category, and certainly having tooltip will be able to help with the confusion the UI causes. We have opened github issues for the rest.
This is definitely a nice alternative to TodoMVC. I like that it's not cluttered w/ obscure frameworks, and the code for each is pretty simple to digest, yet it surprisingly covers a lot of ground (ajax, routing, recursive views).
You should consider re-submitting with a "Show HN" tag.
Hmm, 10 million people is roughly a third of the population of Canada. AFAIK, nothing in recorded history ever killed that many people in a single day. (To give some perspective, the atomic bombs in WWII "only" killed in the range of a hundred thousand people)
If you look at a major terrorist attack death toll, you'll probably find that it's within one order of magnitude of, say, a major riot death toll.
According to those, worst terrorist attack was 9/11, with ~6k deaths in a single day. Most of the riots in the riot list had larger death tolls (ranging from anywhere between ~7k in a single day, to over 1M over a period of time).