Hacker News Reader

Comment by carsongross | Hacker News Reader

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.

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.

View on HN

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.

Or when dealing with some of the offline features of HTML5. Those are literally impossible to do without some local state.

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.

It's not really abuse in an HTML5 paradigm, attributes are meant to be extensible and semantic.

Why not actually use the mechanism that html5 allows for (i.e. data-* attributes) rather than making up your own, that it doesn't?

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.

"No framework"... so here is a framework. Uh hu.

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:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Strict mode applies to entire scripts or to individual functions.

Am I misunderstanding?

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.

http://en.wikipedia.org/wiki/Software_framework

Pay close attention to the 4 bullet points in the first section.

> On "use strict", my understanding was that it applies per script

Yes. However, when you merge scripts, there is only one script at the end.

The site you linked to also mentions this problem.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

"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 [...]"

Ah, OK. Well, good news: intercooler doesn't have an entry point.

Good point on the concatenation issue, I'll fix it for the next release.

> intercooler doesn't have an entry point.

It does.

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.

http://en.wikipedia.org/wiki/Entry_point

"an entry point is where control enters a program or piece of code"

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?

I found that my experience with Dart seems to meet those criteria nicely.

https://www.dartlang.org/

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 found Knockout to be a great middle ground for when "I can do this in jQuery, but it's gona be messy" and "I'm building a SPA".

It hits the sweet spot between easy learning curve, abstraction, and interacting with the DOM nicely.

Sadly, it's not as hip as React/Angular/Ember these days.

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.

Microsoft uses it their recent remake of their Azure portal; this page has a video on building large apps with Knockout: http://jbeckwith.com/2014/09/20/how-the-azure-portal-works/

I'll be honest, I'd be much more receptive to you doing a show hn over pimping the framework in the comments of every js post.

Fair enough.

> 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

You lost me at "That's intercooler.js"

How about using Web Components? They seem to solve most of the problems that JavaScript frameworks try to solve.

Reply on news.ycombinator.com