My theory is that, for much of the web, the perfect javascript framework is no javascript framework.
Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously and think about REST in terms of HTML rather than JSON.
Yes, it's a simple model. And no, it doesn't work for every app. But many apps would be infinitely simpler and more usable in a browser by using this approach, and almost all apps have some part of them that would be simpler to implement using it.
Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously
You can't just say "remove local state and use HTTP instead" - people didn't invent local state from nowhere, it has a lot of advantages to relying on an HTTP call for everything you do. Particularly when you're scaling out widely or when you're dealing with mobile devices.
The irony of suggesting a framework that abuses html attributes in templates to wire up massively abstracted behaviour as a response to someone tearing into the obsession of JavaScript devs with over-abstraction.
You do appear to be overly keen on pimping it, but it looks kinda unnecessary.
Just guessing: (1) it's not actually "data" and this provides more meaningful cues, (2) it provides a bit of namespacing so as to not step on the end developer's own data-attributes, (3) turns out that it doesn't actually break anywhere after all, as proven by many JS frameworks at this point. I tried briefly to track some standards down for you, but I know this gets discussed at length on the Angular mailing lists if you really care for the nitty gritty.
Anyhow, move that "use strict;" line into the IIFE. If it's global, you can't merge that file with other files. Some of the code out there breaks in strict mode. That's why it isn't enabled by default.
Well, it's a library, not a framework: you can use it for as much or as little of your app as you like with as little as a single attribute declaration doing something useful for you.
On "use strict", my understanding was that it applies per script:
Many sites have a build process that concatenates multiple JavaScript files into one. If they concatenate other scripts after yours, your "use strict" will apply to all of them.
Since the rest of your script is already enclosed inside a single function, simply move the "use strict" a few lines down so it is the first line in that function. Then it will only apply to your own code.
> Well, it's a library, not a framework: you can use it for as much or as little of your app as you like with as little as a single attribute declaration doing something useful for you.
If it has an entry point, it's not a library, it's an application. If said application does basically nothing on its own and you're supposed to extend it, it's a framework.
"This syntax has a trap that has already bitten a major site: it isn't possible to blindly concatenate non-conflicting scripts. [...] It is thus recommended that you enable strict mode on a function-by-function basis [...]"
There is an IIFE which is run when the script is loaded. Right before the object is returned to the global "Intercooler" variable, a callback is registered via a jQuery.ready() shorthand.
Practically speaking, this callback is the entry point (theoretically, it's the IIFE itself).
If it wouldn't have an entry point, adding attributes to elements would do nothing.
As a developer that recently made the transition from FileMaker, which is very user-friendly but limiting, to Rails, I love the new possibilities and the fact that Rails provides nearly everything I need and comes with established best practices, but I'm always a little helpless when interactivity (without reloading the page) is required. The apps I'm working on (internal, business apps) mostly work perfectly fine with a document-based approach and most features can be integrated as simple CRUD actions, but from time to time I need just a little interactivity - like in a classic scenario of an order with several line items that needs to calculate and display totals in a form as soon as the input changes. It's that simple, no need for a framework, even most libraries feel overblown for that use case.
I looked at various data-binding javascript libraries, but they all seem like targeting much bigger problems than mine. So I resort to classic jquery, data attributes and ajax calls, but it feels very messy, like a hack not intended to work that way. It may be the fact that I'm new to this but it feels as if I'm missing something very obvious whenever I have to deal with that kind of very basic interactivity and dynamic. It's a simple form that temporarily needs to calculate and process inputs until the user saves the record and solving this seems way too complicated and messy. Are there any options for those simple cases and apps that otherwise would do just fine with a document-based architecture?
You might want to play with React and it's ilk. It's basically a framework for only the view, and it's pretty easy to reason about once you wrap your head around it. You're just asking for calculated fields on change events right?
jQuery is fine for this too, but can become painful to use and organize once you have a lot of DOM manipulations.
React only starts to get complicated once you dive into the Routing + Data Fetching + Flux stuff IMO. React on it's own if you don't need any of that is pretty simple.
I've also had a good experience using Knockout. I used it to add some interactivity to a largely static site, and then expanded its use to create a fairly complex management interface. It's easy to pick up with great interactive tutorials on the web site, and with component support in the latest version you can build some larger web apps.
> Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously and think about REST in terms of HTML rather than JSON.
So basically go back to writing Javascript like we were doing ten years ago?
No thanks.
I was there, it was hell, I hated every second of it.
The Javascript framework scene is very chaotic today but it's exciting, a lot of new concepts and approaches are being discovered on a weekly basis. A lot of them won't pan out but some will, and they will make writing Javascript even more fun than it is today.
And one thing I know for sure: it's hell of a lot more fun to write Javascript today than it was ten years ago.
I get your point but, for me, it was more fun back then. There was more to hack on; heck, you could craft your own selector engine and people would use it. Awesome. Now, seemingly, all there is to do is build yet another CRUD application with whatever framework is hottest.
I'd say not having to worry about 'crafting your own selector engine' and stuff like that leaves you free to spend you creativity on things that are a bit higher on the abstraction ladder. Yes, it makes things that once required creativity more boring, but shouldn't that be cause for excitement that you can now be creative about other things?
This, I like. I'm interested in seeing a progression towards client-side code assembled around libraries like intercooler.js rather than frameworks. I'd like to be able to pick and choose libraries to handle DI, routing, templating, HTTP et cetera in a manner that allows me to tweak/override as needed. I'm fine with foregoing the prescriptive structure that a framework like AngularJS lends to an app - structure is something you will spend time thinking about framework or not, and enough tools exist to let you write modular client-side code without being prescriptive
Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously and think about REST in terms of HTML rather than JSON.
That's intercooler.js:
http://intercoolerjs.org
Here's an image I tweeted trying to explain how to get there mentally:
https://pbs.twimg.com/media/B9QNU-ZCQAECP-K.png:large
Yes, it's a simple model. And no, it doesn't work for every app. But many apps would be infinitely simpler and more usable in a browser by using this approach, and almost all apps have some part of them that would be simpler to implement using it.