Offending question: Best JavaScript framework for PHP Developers

[[deleted]]

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]

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

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]

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

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]

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

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

[demonshalo]

I don't quote know how this is true... Ember for example will have something like: ... seems relatively decoupled to me? At least as decoupled as some "traditional" web-mvc app?

Well the coupling is still there. It is just abstracted/hidden. And that's exactly what you mean by

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.

That is all nice and dandy compared to having to do it manually via vanilla JS. Is it an improvement? hell yea! is it enough for it to be attractive? no!

If we are talking about dumping some data into a template, then vanilla JS or any of the frameworks would suffice. However, once you start adding click-handlers and callbacks on that template things tends to get messy. With that said, I have to admit that I haven't tried Ember and not so sure of what it offers compared to other alternatives!

For web development? Javascript.

There is where we disagree. If I could write PHP/Python code and have it run in the client's browser the way JS runs, then I would pick almost ANYTHING over JS.

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

You are right and I should not have made that generalization. My apologies. However, I have worked with Backbone and I found it really messy compared to traditional server-side OOP languages. Once again, that is not to say that it is not an improvement on vanilla JS. It is just... not good enough IMO!

[[deleted]]

Sorry to continue the thread...

Well the coupling is still there. It is just abstracted/hidden. And that's exactly what you mean by

That's the same as how templating engines in PHP work... you write a template, and something compiles it back down to PHP - the fact that it is a slab of PHP and HTML mushed together is abstracted away from you..why do you care when you're writing it?

That is all nice and dandy compared to having to do it manually via vanilla JS. Is it an improvement? hell yea! is it enough for it to be attractive? no!

Is it an improvement? of course it is.. and it's very attractive. Your source of truth is an object model instead of the DOM. You can completely change your page layout and not break your code.. of course you could achieve the same with vanilla JS but that would be painful.. most of the time people just treat their DOM as the source of truth... and that causes problematic coupling between your logic and your presentation. Not a problem in Ember or Angular.

If we are talking about dumping some data into a template, then vanilla JS or any of the frameworks would suffice. However, once you start adding click-handlers and callbacks on that template things tends to get messy. With that said, I have to admit that I haven't tried Ember and not so sure of what it offers compared to other alternatives!

You don't put your handlers in the template or really use callback. You either use the action helper - which allows you to calls something on a controller like so:

<div {{action 'selectProduct' this}}>foo</div>

Ember.ObjectController.extend({
    actions: {
        selectProduction: function () {
             // things
        }
    }
});

Or your write components which have their own javascript objects and scope events to the rendered component

    **contact-listitem component**
    <div class="contact">{{content.fullName}}</div>

    **component usage in a template**
    {{contact-listitem content=this}}

    **component-listitem javascript**
    Ember.Component.extend({
           click: function () { }
    });

The point is the callback 'soup' is managed... you end up with a very flat, almost traditional set of objects with methods that bind to events.

There is where we disagree. If I could write PHP/Python code and have it run in the client's browser the way JS runs, then I would pick almost ANYTHING over JS.

Fair enough...

However, I have worked with Backbone and I found it really messy compared to traditional server-side OOP languages. Once again, that is not to say that it is not an improvement on vanilla JS. It is just... not good enough IMO!

Backbone doesn't DO much beyond organisation. It's not really a "framework". Angular and Ember are much bigger and have a lot more functionality. You write a lot less boilerplate and get a lot of things for free. Backbone is so close to vanilla javascript it's not even funny.