search

jpdevries / matboard

A Series of Conceptual Proof demonstrated with several different toolkits
13 stars 3 forks source link

VanillaJS example readme #2

Open sottwell opened 10 years ago

sottwell commented 10 years ago

Much of jQuery is now available natively in modern browsers. Complete the proof without using any framework at all.

Of course anybody can write stuff in plain Javascript. I've done AJAX in plain Javascript before it was called AJAX. And MODX would be a lot faster and lighter if it were written in C .gci scripts. Or how about we just forget the whole mess and write a custom website + webserver in assembly language? There's a reason why the Javascript frameworks are so popular. And there's a reason why JQuery is so popular. jQuery is all about the $('CSS Selector')... along with chained .methods() To do the standard DOM Querying with plain JS can take as much as 50 lines of code with many flow controls. And JQuery stops circular references when attaching events and data. That's very hard to manually manage. Not to mention things like cross-browser compatibility. You'll end up with code to do exactly what JQuery does in far too many places.

jpdevries commented 10 years ago

I think this proof is about having a basis for comparison, not really how must faster the manager would be with no framework. It Ditches jQuery for Vanilla JS and uses the mustard test to target only modern JavaScript APIs so that when we weigh the pros/cons of different toolkits, we can compare them to going it with out one at all.

It also is a test in what it takes to keep things abstract. One thing we've learned from 2.x is that we don't want to get bossed around by any given toolkit (such as ExtJS).

Eein commented 10 years ago

One thing that I assume is important is that you want to keep the quality and readability of code high when looking at these types of frameworks.

These frameworks were created to boilerplate MVC/MVVC/MVx frameworks using javascript, and the key function attributed to that is you don't really step out of the bounds of that ideology.

Ember.js has restrictions imposed, but not really any that will effect the creative freedom, but you will have to USE their standards and stick to them or the manager page wont work.

If you use a framework that has coding restrictions, it'll get rid of the support headache down the road in avoiding people accidently leaving holes in their security open when creating 'custom' manager views.

I would go as far to say that if something IS using a framework in the modx backend, the appropriate unit testing should be in place before ANYTHING is launched to ensure that users can't code themselves into a hole.

Currently you dont really see alot of issues because nobody wants to touch extjs because of the stench, but once its more accessible... be prepared!

With that said, Javascript is good to see the performance gains, but i'd say look at it from all angles. Vanilla JS is going to be hard to update, depending on who codes it.