11–20 of 190 posts
I'm also working on a real-time socket.io app and find that I can keep most of the data model logic on the server, and the front-end is focused on user interactions & rendering data. I do use Backbone but only the Views, but the overall architecture of the front end is clean, simple, and minimal.
This has been discussed before. https://news.ycombinator.com/item?id=6653024 A massive discussion between Backbone.js developer and the developer of Riot.js kicked off. It's an interesting read that's for sure. You can find the library here https://github.com/moot/riotjs
Not 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.
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...
http://facebook.github.io/react/blog/2013/11/05/thinking-in-...
Now, how about CSS? So far, I've reluctantly chosen Bourbon + Neat + Bitters, which are nice, but not ideal. I appreciate the Sass and semanticism (semanticness, semanticitivity) of it all — no more Bootstrap-like class names in my HTML! However, there aren't enough examples of real pages built with these tools.
Thoughtbot, if you're listening, why not publish at least the Sass sources of these webpages?
Unless I'm blind, this post contains everything except usage examples or source code for your framework. I'd be interested in seeing it for myself, not only in hearing how cool it is.
Suggesting that frameworks are too complicated because they "add tens of redundant methods, adding complexity for the end user" is ridiculous. The number of methods in something doesn't always add to the complexity - in a lot of cases a framework vastly reduces the difficulty of using something by abstracting away the hard stuff so the user doesn't need to worry about it. That's pretty much the point of a framework.…
Eg, the primary value of Angular is binding DOM -> data. As a developer, I want to specify:
- The template for the DOM
- The data
That's all. I don't care about $scope.$apply, a second module system (even if it's better) or anything else I have to read about.
Ractive.JS (The Guardian's framework) does this. It's just mustache templates you bind to data, and when the data changes, the relevant parts of the DOM do.
The 'how to' fits in a tweet, it's backed by a major media company and the lib is 32 kilobytes.
How disappointing, the article is called "Frameworkless JavaScript", but the author uses jQuery for the application. Yeah, I get it, jQuery a library... File size seems like the biggest concern, but really, how important is that on a dynamic page that needs to load exactly once? And using a CDN it might already be cached anyway. That being said, I also like clean, minimal JS code.
It is refreshing to see this post. As someone who has tried, and not really taken to, all three of those frameworks I sympathize. Stick with what works for you. Shipping code on your own terms is the end goal. The customer viewing the page does not care one iota what framework you are using.
Moot's customers are not the people viewing the discussions; their customer is the developer integrating their code into a website. A framework might be important to them. If their argument was "We didn't like any of the frameworks so we built moot without one" that'd be great, but they're making the case that all developers would be better off without, and that's pretty damn dubious.
I'm not really seeing the size advantage here. All of the mentioned frameworks are cached on popular CDN's and I just don't think you're really getting much of a win out of creating your own, smaller files.
Also, I'm always wary of companies that want to re-invent the wheel as opposed to using open-sourced, well-documented projects. If I start at your company and you use Backbone, not only is there a good chance I can come in with a good understanding of your code -- but I can easily check on Google for any questions I have. If I start at a company that has built their own, closed-source, custom JS framework -- I'll have to ask internally every time I have trouble figuring something out.
It may be necessary for your product, but to me it always raises a flag when people create their own proprietary version of something that already has been done.
Anyway, a great read for sure!