Human JavaScript

Just pass {debug: true} to build function.

I'm not sure if there's something different about TS and React but I'd imagine if they have source map support it should work similarly?

For React JSX, you can use the browserify transform reactify. For typescript, you can use typescriptify. They should be right there in npm :)

If you're using karma as a testrunner though, I highly s suggest karma-browserifast over karma-browserify. It's orders of magnitude faster, and supports the latest jasmine and karma (the former does not). The former runs in O(n!) where n is the number of spec files. Yikes!

You can use login pages to prime caches, pre-render, etc. That's certainly not a panacea, but can help.

With the right cache headers on the main application assets and a primed cache you can start executing code immediately and eliminate all but your data calls on a good portion of app loads. From my experience, with a primed cache it's not too difficult to get comparable load times to opening a native app.

I'm hoping ServiceWorkers, Improved local databases, and HTTP 2.0 can help us out here.

There's also the option of trying to do the initial render server-side. I've experimented a bit with this, and have some more thoughts and approaches I want to try for this. But, I have yet to see someone do this is a way that didn't add a significant amount of complexity to the codebase :-/

Aliases are also ugly in my opinion, given that they can be reassigned any old time. Even the much-used dollar sign alias demands extra scrutiny, when inspectng unfamiliar code. The advantage is that they're (aliases, that is) are easy to write, not easy read. On the other hand, the "contains" function should adhere to the sanest contract most would expect from it, and if it does, "contains" is easy enough to understand. But yeah, depending on libraries is either laziness or bullshit, when it comes to core language functionality. The only thing advanced libraries really offer is cross-browser compatibility.

Meanwhile, (x.indexOf(y) == -1) is dead simple, as long as you know that arrays start at zero, never have negative indices, and that indexOf() returns a negative value when the argument isn't matched by an object in the array. Returning a negative value, as parlance for "not found", when an absolute integer value is expected, is a pretty sane convention.

   Tools where you build the app by writing code in
   JavaScript files, not by trying to declare too much of 
   your app logic in your HTML (no AngularJS, sorry).

   The DOM is simply a view of the state and reacts to 
   changes in the model layer.

that said, this:

   People who already know JavaScript should be able to 
   work on the app without lots of knowledge about a 
   specific tool or framework.

I've been using ExtJS since 2008, so I can give some experience here. What he says is absolutely true. The DSL of ExtJS does slow down ramp-up for new developers and requires an investment in learning the framework before you can use it.

However, I would like to point out there is a reason for the DSL. The DSL abstracts away the low level details of HTML so you can think at the level of ui elements. HTML's controls are very basic. Instead of comboboxes it has selects, which are quite inflexible. Instead of grids it has tables, which are also quite weak. The date field is minimal and in fact missing in older browsers. The list goes on and on. HTML is simply not rich enough to express desktop-level ui's elegantly. You can deal with that in two ways: embrace it and dumb down the ui (hence the trend towards minimal ui), or work around it and build a DSL on top of HTML. The core theory behind the rich DSL of ExtJS is that by bumping up the abstraction level developers can be more proficient. It is OO encapsulation at the UI level.

That is the theory. In practice it is a mixed bag. You have the same problem with ExtJS on top of HTML as you have with an ORM on top of a SQL db. You need to understand both what happens underneath and what the tool does on top of that. The cognitive load is higher, not lower. Some people thrive in that and are more proficient in the DSL than they would be in a raw templating view-driven environment. Others struggle with the larger amount of layers involved and are slowed down by the approach, and then some people fall in between and see no productivity difference. YMMV.

Update: one additional thing that I'd point out is that being opinionated and investing deep with a framework is not a bad thing when you're building a large long-lived codebase. If you're going to be living in a codebase for years, it makes sense to have as much application backbone (pun intended) as possible before you start building code on top of that. If you assemble a hodge-podge of smaller modules you're essentially constructing your own big framework anyway, so you might as well bite the bullet and choose a consistent one. The notion that you're ever going to switch js frameworks on a large single-page-app codebase is silly. The cost will always outweigh the benefits.

Now I'm forced to use Angular and frankly, I'm frightened. There is no room for designing the architecture of my app - it's been taken care of - yet I'm still going to be held responsible for this architecture shortcomings, if I happen to stumble upon some of them.

Of course, codification of some conventions may be convenient and so I'm not against frameworks in general. But I know that sooner or later I will need an escape hatch to do something less than conventional and I want my framework to just get out of my way for a while. That's what Pyramid does and what Django starts to support in recent versions. I'm not yet familiar enough with them, but I suspect Angular, Ember and some others are not that great in this respect.

In short, while I never was very interested in front-end development, I did build some single-page apps, and I - after skimming a few chapters of this book - always worked similarly to what the author proposes. I really do hope that this approach will become dominant (once again, everything old becomes new again and all that), if for no other reason then because I just enjoy designing and writing in this style more.

[PS. It's nice to see you're still alive :)]

* Use something that is HTML-aware instead of something that treats HTML as text. Even if you have the template engine still spit out HTML strings in the end its going to be able to escape user data in a context-aware manner and get rid of useless whitespace.

* Logic in templates is fine and separation of concerns between view and model does not have to mean using different languages for them. My impression is that most "logic-less" templates eventually reinvent broken versions of variables, loops, conditionals and subroutines so I would rather use a real language from the start. An example I like is giving different classes to odd and even rows in a table. The solution is obvious if you use regular loops but can be quite tricky in many template engines.

ETA: To elaborate a bit, "interfacing with an external API" is usually just a fancy way of saying, "making HTTP requests." In Javascript, this means using the XmlHttpRequest browser API, which people call AJAX because it sounds hip. You can use it directly, but jQuery gives some extremely convenient helper methods for easily composing requests. One thing to keep in mind is that if the API uses JSON, you will have to consider that the browser does not permit you to return JSON from a cross-domain request (which an external API call almost certainly is). There is a way to enable this using something called JSONP [2].

[0]: https://developers.google.com/api-client-library/javascript/...

[1]: https://api.jquery.com/jQuery.ajax/

[2]: http://json-p.org/

But just to add my 2 cents for working with API's specifically - on the server side - a good start might be to play around with Node and CouchDB. Try building a basic app.

Couch is a database with an HTTP API out of the box, so if you can get the hang of it's basic operations then you will inherently have the fundamental knowledge needed to work with just about any other API.