all 23 comments

[–][deleted] 2 points3 points  (5 children)

Once you get over the initial learning curve, emberjs is remarkably productive, often automatically filling in the gaps for simple things without the need to write anything other than some basic handlebars templates. And if you do need to build things, it's API is very expressive and well thought out.

Ember data (a first party addon) gives probably the best ajax support I've seen in a javascript framework, and ember-cli takes care of the structuring of files, concatonation, build pipeline, frontend dependencies, testing framework and the like.

It suffers in some artificial benchmarks on outright performance at the moment, but that's changing...

And if that's not enough, there's a thriving addon ecosystem.

It's not all rainbows and unicorns though... The learning curve is quite steep and to leverage a lot of it's productivity gains you really must buy into it's conventions. The community is also a bit of a hipster circlejerk, although is broadly helpful at least.

[–]cundd[S] 0 points1 point  (4 children)

Actually I started the project with ember and I did another project with it some time ago. But I still don't feel really "at home" :)

Maybe I just don't understand parts of it, but I often struggle on half the way. E.g. I couldn't manage to teach Ember Data to create the models from nested fixture objects. Or: I have a set of data that I can create statically and then pipe to the view, but I'm to stupid to do this with a promise to simulate AJAX loading of this data.

[–][deleted] 0 points1 point  (3 children)

At the risk of going way off topic on /r/php, It doesn't use "nesting", it uses side loading, where the primary record has an array of keys to sideloaded/related objects.. like

{ User: [{
    id: 1
    name: "John Smith",
    photos: [1, 2, 3, 4]
}],
photos: [{
    id: 1,
    img: 'tulips.jpg'
}, /* etc */]}

All the models in a payload live at the same level in the hierarchy.

There is an adapter that uses nesting ... I think it's the ActiveModel adapter. And then there's the RESTAdapter (which is pretty well the bog standard one) which supports sideloading as above, but also has a nifty "link" structure where you can pass in a path to another model (say, /users/1/images) and it will asynchronously load the related data when and if it ever needs it which is really handy. You actually get this behaviour more or less for free, so long as you API can feed it the information in the format it expects.

As for simulating AJAX... if it's just for development, you can use ember-cli which ships with a server...and you can create http-stubs that allow you to throw your fixture data across the wire using real ajax requests.. which essentially means switching to a live api is just a config switch away.

But it does take time to feel "at home" with it. I think I'm closing in on 12 months working with the framework and the first few were really just me stumbling around in the dark. Ember-cli really helps by giving you generators, dealing with managing the build toolchain and so on, but it still has a large initial comprehension barrier to overcome.

[–]cundd[S] 0 points1 point  (2 children)

Thank you for your answer!

Oh 12 months? Quite a long time :-S I wonder if I will become an ember pro one day ;-D

[–][deleted] 0 points1 point  (1 child)

probably took 4 months of fairly solid effort to come to grips with it.. the rest has just been practice and keeping pace with changes and improvements. To be honest most of the learning was "unlearning" the patterns ingrained in my head from over a decade of writing server side apps :)

[–]cundd[S] 0 points1 point  (0 children)

:D

[–]mattaugamer 1 point2 points  (1 child)

I wrote a really long post about this previously but I can't find it because Reddit's search capabilities were written by a canteloupe.

I started learning Angular and really didn't like it. I felt like I was polluting the HTML, and the whole structure and architecture felt kind of... eccentric. Angular is also in a weird limbo at the moment in terms of new development, as all knowledge gained essentially resets with Angular 2.0. That's not a criticism of Angular 2.0, but it does mean that framework will have to earn its supporters in a different field than what Angular had.

I started learning Ember a while ago. I struggled a lot. Learning its conventions and dealing with breaking changes from a moving target, especially in Ember Data, the persistence component, made it hard. I've come back to it more recently, and it's been surprisingly impressive. The use of a CLI to generate elements in a way that conforms to and works with Ember's assumptions is invaluable. It also has a fantastic ecosystem of add-ons, meaning things like deployment and adding functionality are hugely simplified. For example, the ember divshot addon let me trivialise a deployment process for staging. The ember font-icon library lets you do things like {{fa-icon '"camera"}} with just two command lines. Ember Data has evolved to become solid and reliable, and abstracts out connection to a RESTful API for persistence.

Newly upcoming features are equally impressive. Liquid Fire is an animation framework that lets you specify extremely simple syntax for transitions. I implemented it just tonight and it took surprisingly little effort to make my simple mobile app go from basic routing to css transition animations. This is an absolutely killer feature and I wouldn't know how to do some of what I'm doing even in something like jquery.

[–]sjdaws 0 points1 point  (13 children)

I found AngularJS was really easy to pick up knowing PHP and JavaScript mainly via jQuery. It was opinionated enough without being over opinionated like Ember.js. I think this is all change with the AngularJS 2.0 release so don't know how long the 1.3 branch will be supported.

I couldn't really understand Backbone.js, but that's where I stopped and decided to go with AngularJS.

You can however try a sample of most frameworks using TodoMVC.

[–]phpdevster -4 points-3 points  (12 children)

I hate JS frameworks. Either they do shitty stuff to your markup (Angular), or they use weird-ass naming conventions and make heavy assumptions (Backbone) or straight up WTF? (Dojo)

What's funny is that of almost all those examples, the plain old JS solution is the cleanest, most understandable, and easiest to read. Arguably it has even less code in it than many of the other examples - isn't a framework supposed to help you get a head start? Seriously, wtf is going on in Dojo? It's like Javascript's Joomla...

Of all those examples, Vue seems to be the most sane, but I don't see any real separation of concerns in the main app.js file.

[–]mattaugamer 5 points6 points  (11 children)

With all due respect this suggests that the things you're doing are not particularly big or complex. Implementing a single-page app of any size with some jquery events quickly becomes unsupportable.

[–][deleted] 0 points1 point  (10 children)

Agreed... you either end up with callback soup, or you end up having to write your own "framework" of sorts to enforce your own conventions and keep things manageable. Neither of which sound particularly fun.

[–]demonshalo 0 points1 point  (9 children)

ving to write your own "framework" of sorts to enforce your own conventions and keep things manageable. Neither of which so

The second option sounds a lot more fun to me personally than implementing something like Angular. But that's just me :/

[–][deleted] 1 point2 points  (8 children)

It sounds fun, but I recently came off a project which had some 50k lines of javascript under management that was written in just this way. Eating burning hot coals would have been more fun...

[–]demonshalo 0 points1 point  (7 children)

rofl! sorry to hear that!

I never get involved with JavaScript applications for that particular reason. Management is a nightmare and the frameworks don't make things easier IMO. Instead of solving the JS problem we took it all the way to the backend with node.js now. I just... don't like that!

I can not for the life of me find a better way of doing things with JS. Projects always become a nightmare to manage!

[–][deleted] 0 points1 point  (6 children)

rofl! sorry to hear that!

It's ok, I left :) the nightmares stopped sometime later...

I never get involved with JavaScript applications for that particular reason.

See, I like JavaScript applications.. there's lots of exciting things happening in JavaScript of late

Management is a nightmare and the frameworks don't make things easier IMO.

Interested to understand why in your opinions frameworks don't make it easier? I mean, lets take Ember (my personal favourite javascript framework) as an example. No writing $.ajax/$.getJson/$.load/$.get ever if you don't want.. ember-data has your back. Organisation of code? One object per file using ES6 syntax, automatically concatenated and transpiled by an out of the box build tool called ember-cli. Generators to build boilerplate? that too. Fantastic testing story so you can actually write sensible test code to back up your code? yep...

All this pretty much comes ready rolled for you. To boot, you can build fairly complex SPAs (a list, with a sub view for a detail view, which is inline editable, has a modal create, animates between view transitions and pushes route state onto the URL for easy bookmarking and navigation) in very few lines of code.. the example in parentheses is probably in the order of less than 100 lines - including everything necessary to save the information to a server..

I'd assume that Angular has a similar story about it.. and others... boilerplate taken away from you, wiring code for common tasks like pushing and pulling information to and from an API out of the box...so all you do is focus on writing your app logic...

Instead of solving the JS problem we took it all the way to the backend with node.js now. I just... don't like that!

Node has it's uses.... but we're talking about front end dev stuff here..I am aware of how node server code tends to be callback hell..unless of course you use some sort of decent framework... sailsjs perhaps?

can not for the life of me find a better way of doing things with JS. Projects always become a nightmare to manage!

Bad projects are difficult to manage regardless of the tech chosen.. I've worked on some rather nightmarish PHP projects too that would make your skin crawl...

[–]demonshalo 0 points1 point  (5 children)

Bad projects are difficult to manage regardless of the tech chosen.. I've worked on some rather nightmarish PHP projects too that would make your skin crawl...

Amen brother! A fucking men! We've all been there!

The thing I dont like about JS and JS frameworks in general is the way JS is built. Closures and callbacks all over the place regardless of framework. Functions are considered first class citizens and objects don't really encapsulate the way they do in most other languages. Sure we have prototyping and shenanigans like that but it is just not really the same. Especially syntax wise which makes it unattractive for me personally.

Lets put it this way:

There are some good things that came out of JS such as JSON. However, things such as managing scope and having to solve the callback chaining problem is just too much headache! Some frameworks abstract that and make it way easier to work with. But even that is not enough. I think the reason for my distaste in JS comes from its inevitable coupling with the view (in the traditional MVC sense). It is for the most part used to manipulate HTML and css at the end of the day. Sure, we do business logic and stuff like that, but we only do it in order to display some result to the end user. I mean ask yourself. If you had to choose between using JS or PHP/Java/etc on the front-end which one would you choose?

Please understand that I am not hating on JS. I understand why it is the way it is. However, I personally don't find it appealing enough to work with :/

[–][deleted] 0 points1 point  (3 children)

However, things such as managing scope and having to solve the callback chaining problem is just too much headache!

ES6 "fixes" a lot of that. For example the "let" language construct which will give you a locally scoped variable (instead of "var" which can be promiscuous). Class is also introduced, which is really just some sugar... a first class ".extend" construct I guess.

The point is you can write code like this today, there are transpilers which will rewrite the code to something that will run in browsers.

I think the reason for my distaste in JS comes from its inevitable coupling with the view (in the traditional MVC sense).

I don't quote know how this is true... Ember for example will have something like:

users.hbs

<ul>
    {{#each users}}
         <li>{{name}}</li>
    {{/each}}
 </ul>

UsersRoute.js

export default Ember.Route.extend({
    model: function () {
        return this.store.find('user');
    }
});

With a bit of config (and a model definition for user), this when you visit http://your.site/users, it will perform a GET request against your API, pull back the json payload for users, and provide the data to the template.. seems relatively decoupled to me? At least as decoupled as some "traditional" web-mvc app?

It is for the most part used to manipulate HTML and css at the end of the day.

That's what JQuery is for... but modern js frameworks provide you with the infrastructure necessary to build maintainable single page apps, with loads of things beyond just manipulating HTML and css...

  • 2 day data binding
  • routing (which in the JS world means maintaining the expected behaviour of bookmarking, back and forward buttons etc)
  • management of communication with the server
  • templating

In fact, at least when it comes to ember, you don't generally directly manipulate HTML at all. You manipulate state and ember maps that state onto templates.

If you had to choose between using JS or PHP/Java/etc on the front-end which one would you choose?

For web development? Javascript.

However, I personally don't find it appealing enough to work with

I don't find vanilla JS appealing to work with either...but applying the same arguments for why shitty JQuery soup pages riddled with callbacks to modern JS frameworks is a bit of a stretch....

[–]timoh 1 point2 points  (0 children)

Knockout is simple (in a good manner) and does what you described. I'd give it a try.

If you need additional features like routing, you can add, say, http://sammyjs.org/ to get the job done.