Hacker News Reader

Comment by psychometry | Hacker News Reader

Is there a Javascript MVC framework that actually has good documentation, guides, and code samples? I've been working with Ember.js, but it's incredibly frustrating trying to learn a framework whose documentation is incomplete.

The other problem I've found is that docs, tutorials, and Stack Overflow posts that are even six months old are often completely useless when troubleshooting bugs in Ember.js or even learning its basic features.

It seems Angular suffers from the same complaints I have about Ember.js. Those of us who really need to just "get things done" might be better suited by a mature, well-documented framework, but does one actually exist?

View on HN

> Those of us who really need to just "get things done" might be better suited by a mature, well-documented framework, but does one actually exist?

No.

Frameworks are all the same in that they are great at getting you to about 80% of what you need REALLY fast. The next 10% takes some investigation but its doable.

But that last 10%. Its like pulling teeth. You're working for the framework rather than it working for you. In my experience, all of the time gains you realize from using a framework early on are lost (and then some) trying to get it to do that last 10% that you need.

Ultimately I've found that using vanilla Javascript offers everything I need to just "get things done" and complete a project successfully. Sure, I might not be able to get something out the door in a day. But at the end of the project I've delivered clean, maintainable code on time. And anyone who knows Javascript will be able to read it.

Now, lest you think I'm a complete framework hater; they have their place. They're great at prototyping, for example. But never again will I build an entire project on one. I have little interest in being a glorified glue stick, piecing framework code together. How boring.

I should add that I make heavy use of libraries like jQuery and Underscore. They're libraries, not frameworks. Take what you need with them yet still reasonably lightweight. Frameworks are bloated, tightly-coupled, poorly documented monstrosities in my opinion.

Finally someone said it. Even if I write more code by only using libraries and no frameworks (which is debatable), at least I'm happy while writing it.

I do consider some frameworks to be exceptions though. Express is called a framework but it looks more like a library for HTTP handling to me. Most npm packages behave like libraries - maybe that's why I like using Node.js so much. Also CSS "frameworks" like Bootstrap aren't in the same league. They've never caused me the type of frustration I've had with frameworks like RoR or Angular. Bootstrap is actually a library of UI widgets. They can call it a "framework" but I don't consider it to be one.

I think it depends on how good you are. If you're a great developer, with deep knowledge of patterns, a strong commitment to refactoring, with lots of experience such that you're aware of the pitfalls you are likely to befall, then you're probably right: frameworks will buy you little.

I'm pretty good, but I'm apparently not good enough, because I find myself consistently learning things from frameworks. I certainly am familiar with the Last Ten Percent you're talking of. But I also know that for every 10% that I have to pull teeth to get, there are many many things that work well because the platform team did a great job and drew on a depth of experience and expertise that I just don't have yet.

DHH built a lot of Ruby apps before he built Rails, and by using Rails I can draw on his experience. As a solo founder that's worth a lot to me. And even now, when I've largely moved on from Rails I still draw on things I learned from studying that framework. And the frameworks I use now are equal distillations of very deep experience.

You're perhaps a more experienced developer than I am, or just better suited to the job.

You touch on one of the other benefits of a framework; they're a fairly decent way to learn. But, unfortunately, much of that is because you're learning what NOT to do.

A much better way to learn is to go write your own framework. Then you're forced to encounter the pitfalls and overcome them through research, trial-and-error, and interacting with the community.

But continuing to use a framework is just a crutch in my opinion. At some point not only are you not learning anything but, as I mentioned before, all you're really doing is gluing framework code/modules together. You're actively doing yourself a disservice and letting your skills atrophy by relying on such a crutch.

One thing about frameworks that I find interesting is; how many were used to develop Unix? None. Because there weren't any back then. And now its in billions of devices worldwide.

I did this myself. It was crap. Fun to write, and I learned a lot from it. But still, monolithic, poorly documented, tightly-coupled crap and even I don't use it anymore.

I felt like Backbone.js (when I was actively using it) had really clean and complete docs. Couple that with the fact that the source is incredibly readable and debugging anything strange was never that tough.

Sure, but Backbone does a fraction of what Angular does. And, it's pretty consistent with how most people write JS anyway -- whereas Angular pretty much re-envisioned everything.

You say that like it's a pro but I'm pretty sure it's a con.

It depends on your point of view. Personally I've never been too happy about the state of JS code, so trying something different is absolutely a good thing.

Is Angular the best approach? Is there even such a thing as a best approach? Probably not. Look at the proliferation of server side frameworks. They each have their pros and cons.

I do like that Angular is a real framework, rather than a library that only gets called a framework. It handles all sorts of stuff for you in the same way serverside frameworks tend to do.

whereas Angular pretty much re-envisioned everything.

Angular is the first time I've written a web-app and been completely lost from second one without a fully stateful JavaScript debugger willing to break at any point and letting me inspect the call-stack, parameters and locals.

Everything which was simple about the web up until now, Angular transformed into horrible, black voodoo magic which either just worked or didn't at all.

If that's what "re-envisioned everything" is all about, consider me out.

To each their own, I guess. I've rewritten numerous apps in a fraction of the original time (and original line count) using Angular. There's a bit of a learning curve, but once I started "thinking Angular" (aka, if you're touching the DOM you're doing it wrong), it was great.

> Everything which was simple transformed into horrible, black voodoo magic

That's what radical re-envisionings always look like. Anything that fits easily into your toolbelt is an incremental improvement. That's what the word "radical" means.

The promise is that after doing some hard work to learn new data structures you will be more powerful, but it's certainly your right to be skeptical of that.

I started with Ember about a year ago and the getting started docs were pretty terrible. It took a lot of experimentation and frustration before I was comfortable developing with it. Eventually I became familiar with the framework and the API docs are quite in-depth, not really great for a beginner though. After about four Ember projects I can now prototype a large app (using something like Bootstrap) in a day or so, so I feel that pain at the start was worth it. Back at the time though I was tearing my hair out, especially over router changes. The changes improved things by an order of magnitude though. I trust the Ember team, I'm happy now, the start could have been easier.

My experience pretty much parallels yours. These frameworks are at the cutting edge. Only a handful of big apps have been made with Ember or Angular, and so the core teams are constantly bumping up against weaknesses in their designs which can only be addressed by making changes that break apps.

From reading the Ember discussion lists I get the strong sense that the core team is willing to make difficult breaks, but that they really try to only do it when it's absolutely necessary for the long-term robustness of the platform. A lot of thought seems to go into which problems are getting solved now, which are put off til later, and which interfaces get torn out and rewritten.

I just spent several weeks upgrading my app from the earlier Ember RCs to Ember 1.0 and the latest Ember-data, and while quite painful, I feel good about it because I don't think the core team made those changes lightly. My sense is they are looking out for us.

I'm currently working on a big Angular app that is about to move into production (although it's not to be something that's widely used in public) - we have found that Angular causes everything to be structured in a nicely organized fashion overall. This app is not structured perfectly by any means either, due to bad design on some of our pre-existing code base.

From what I understand, big Ember projects have turned out well for Ember devs - I can confidently say that I feel the same way about big Angular apps. I have built several big ones, including an online assessment platform (frontend by myself) and an online assessment platform/management system (with a team of ~10, 3 of us on frontend).

From my experience, the Angular team has thought things out on a high level, which I greatly appreciate. They are big consumers of their own product, as Angular is used quite a bit with Google's own sites - here is an example of an Angular app, with Angular being used to implement parallax scrolling (and probably more): http://www.google.com/nexus/7/

Check out KnockoutJS, I've found their documentation to be quite good and it's a pretty easy framework to learn.

KnockoutJS.com is by far the best in terms of documentation and usability for novices.

Does anyone have experience with Enyo (the framework from WebOS)?

It claims to be adding MVC support in the next release.

Reply on news.ycombinator.com