Until recently I didn't even know that there was a status quo in the frontend development. I worked with JavaScript in exactly the same way I'd work with any other language where stdlib is minimal at best (like Scheme or C) and that was to design the app, fill as many blanks as possible with libraries and write the rest myself.

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 :)]

Hi, likewise :)

On topic: agree on Pyramid / Django comparison. It was a nice, eye-opening experience to work on Pyramid project after only Django-based ones.

Though I doubt the same applies to Angular / Ember.

My personal opinions on templates, for Javascript and other languages are:

* 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.

I generally agree with him regarding the picking your tools part, but some of it seems a contradiction.

   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's pretty much Angular's philosophy as well.

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.

IMO trumps all.

My main point was just that it's never felt right for me personally when I try to write too much logic into templates directly. Because at the point where you hit the limit of what that abstraction supports you now have to solve that problem outside of the abstraction, fragmenting your code.

/me shrugs

It's all about how much you actually need to customize beyond what you get from something like angular out of the box.

I'm not wanting to fight a framework war, that's for sure. If angular works well for someone, that's awesome they should keep using it.

The item you pointed out in the second quote, yup... that's a big deal for us.

I'd like to comment on this remark: "Tools that are "just JavaScript." Not tools where you describe your app in a DSL (no Sencha). This is to avoid requiring too much knowledge of the framework itself before being able to contribute. Focusing on JavaScript also offers some protection against investing too heavily in framework-specific knowledge."

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.

Sencha/ExtJS does certainly give you a lot of stuff out of the box, which is really cool. The main pain points I had were when building with it emerged when I had to do something that wasn't supported out of the box.

Picking the right abstraction layer is a fine line to walk. As you pointed out, there's tradeoffs on both sides.