So when OP says none of the popular framework works for him, he doesn't want to be locked in with another framework, he created his own MVC framework Motto. That sounds contradicting. You now locked into your own framework.
Frameworkless JavaScript
61–70 of 190 posts
Re: Frameworkless JavaScript
#62Earlier quoted context omitted.
Ractive.JS doesn't need $scope.$apply because it uses it's own model system. AngularJS doesn't use it's own model system, the model is a plain old JavaScript object. The author of 'Frameworkless JavaScript' criticizes the Ember way of using a "complex model system". $scope.$apply exist because of limitations in JavaScript. Apparently this will be fixed in ES6, so ES6-version of AngularJS theoretically won't need $sco…
Ractive uses POJSOs. Each binding has a POJSO (ie, an Object, nothing magical, no new inheritance system or unrelated class-based OO system) and a template (in mustache format). That's all. You can make the binding live specifying 'magic: true' which requires ES5 (a reasonable requirement for modern web apps).
I stand corrected. I thought you needed ES6 for that, but apparently ES5 is nearly enough.
I didn't read about Ractive.js's magic mode. It's not automatic data-binding either, according to the docs[1]:
'Magic mode only works with properties that Ractive already knows about.'
1. http://docs.ractivejs.org/latest/magic-mode
AngularJS works with properties that it doesn't know about, if you use $apply.$scope.
Re: Frameworkless JavaScript
#63You are going a dangerous way. As long as your team and code base are small, a self-cocked solution has its advantages. But when you use one of the frameworks, your app gets a structure that other developers can easily understand, because they know the concept. They easily find points where to debug and where to breakpoint. Using a proprietary framework has none of these advantages. Every new developer needs more tim…
>You are going a dangerous way. As long as your team and code base are small, a self-cocked solution has its advantages. But when you use one of the frameworks, you app gets a structure that other developers can easily understand, because they know the concept. They easily find points where to debug and where to breakpoint.
For one, your app can have a structure even with your self-coded solution. That's the job of the programmer, not of the framework. Besides, the framework's structure is not tailored for you app. It's the one-size-fits-all structure its developer likes to think in.
Second, while using a framework might has some benefits for a slightly larger team, when you go even big it loses the benefits again. In fact a lot of the big companies are using their own framework (which they self-coded).
Re: Frameworkless JavaScript
#64I've used Backbone for a couple projects. Then I used Angular because I liked the two way binding and easy access to history. Still, I generally find that these frameworks get in the way for most of my projects. I tend to use the following structure: (function () { 'use strict' var n; $(document).ready(function () { // Event listeners here $('#some-id').on('click', n.Product.respond_to_some_click); } // Sometimes I o…
Launching a massive project with that exact same structure soon. No problems at all. Feels so flexible.
Re: Frameworkless JavaScript
#65I've just gone through a similar process of reviewing and discarding a number of JavaScript frameworks. I've settled on React, and I can't recommend it enough! React handles mostly the V in MVC, and does an admirable job of it. It even provides a cross-platform event abstraction, which would've saved the author some trouble. http://facebook.github.io/react/ http://facebook.github.io/react/blog/2013/06/05/why-react.ht…
What do you use for the models and routing?
Re: Frameworkless JavaScript
#66As a JavaScript developer who spent much of his early career writing framework-less JavaScript (as many of us did in the not too distant past), the sentiment behind this post really rings true to the way I feel about programming for a client like the browser. Modern frameworks are all young and imperfect in their own ways, every byte counts and JavaScript is certainly powerful and expressive enough to get you by with…
The other big benefit of popular frameworks to businesses is that they're more likely to reach maturity faster with more people using, fixing, and contributing to them. With frameworks, bugs, security holes, and performance issues - especially the hard-to-find edge cases and gremlins - once solved are solved forever (more or less), whereas every time you start your own new framework you have to deal with that again.
It's probably best for a business, if you want to give your employees experience architecting a framework instead of just using one, to standardize on something like Angular.js/Ember/React/etc and then encourage/incentivize your employees to become contributors to it. Almost best of both worlds - benefit from using the framework, and employees get valuable experience, resume builders, and connections. Only thing they miss in that scenario is architecting a framework from scratch, which is something only your early employees would have gotten to do anyway.
Re: Frameworkless JavaScript
#67Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running.
This sentiment, expressed collectively, commoditizes the entire profession. How can you expect to ask for raises if all devs are basically interchangeable? If we've eradicated all notions of design, and follow prescriptive rules of structuring and solving problems that anybody can Google and follow, then what avenues are left to express technical ability? What differentiates you?
"then what avenues are left to express technical ability"
I dunno, maybe actually solving problems for clients instead of playing endless rounds of "my JS is smaller than yours"?
Re: Frameworkless JavaScript
#68I've just gone through a similar process of reviewing and discarding a number of JavaScript frameworks. I've settled on React, and I can't recommend it enough! React handles mostly the V in MVC, and does an admirable job of it. It even provides a cross-platform event abstraction, which would've saved the author some trouble. http://facebook.github.io/react/ http://facebook.github.io/react/blog/2013/06/05/why-react.ht…
+1 react, I also believe it would satisfy OP's need. React is going to take over the world in the next 5 years
Re: Frameworkless JavaScript
#69While I agree with the salient point in the article, I disagree with the emphasis on the size of the script. If using a framework reduces headaches and saves developer time, it will be significantly less expensive to use the framework than to roll and host your own solution. ALSO, there exist cheap/free CDNs that host many of these libraries: backbone -- http://cdnjs.com/libraries/backbone.js/ rainbow -- http://cdnjs…
CDNs are not magic and there's a lot more than bandwidth to consider: you still have the overhead of doing DNS lookups, additional server connections and response latency before bandwidth enters the picture and the client overhead of decompressing, parsing and processing the response, where CSS will block rendering until it transfers and JavaScript will not only block rendering but also further loads until it finishe…
The magic of CDNs is caching. So, if you are using, for instance, the URL "//code.jquery.com/jquery-2.0.3.min.js" on your site, and the user has already visited a bunch of sites which are using that URL for their jQuery (highly likely), it means that there is no re-download because the browser already has the DNS and JS cached. Perhaps one extra hit to check for a 302 (and sometimes not even), so the thing about CDNs is the idea that when people hit your site, they already have the libraries you are using locally.
In this regard, you should exclude well-used resources that are on a CDN from your packaging/build process.
Re: Frameworkless JavaScript
#70I've used Backbone for a couple projects. Then I used Angular because I liked the two way binding and easy access to history. Still, I generally find that these frameworks get in the way for most of my projects. I tend to use the following structure: (function () { 'use strict' var n; $(document).ready(function () { // Event listeners here $('#some-id').on('click', n.Product.respond_to_some_click); } // Sometimes I o…
This approach is fine for small projects but you'll run into organizational problems once your application's complexity grows. For example, how many event listeners are you going to pile into that $(document).ready callback before you decide to break things up? How do you organize your code if/when you separate your listeners.
Another aspect your code doesn't address is fetching/posting data from/to the server, which leads to many more tangles, especially once you start duplicating code between models, etc.
Anyway, this isn't a criticism by any means. If such a lightweight approach is working well then you're doing it right. I'm just pointing out that things can get hairy as your app needs to do more and more.