I would love to see a comparasion with knockoutjs/durandal too...
Show HN: My new JavaScript MVC framework
131–140 of 167 posts
Re: Show HN: My new JavaScript MVC framework
#132Have you successfully tried this out in a real app? Why would you want to structure your dom inside an array? Seem pretty crazy, my dude. todo.view = function(ctrl) { return m("html", [ m("body", [ m("input"), m("button", "Add"), m("table", [ m("tr", [ m("td", [ m("input[type=checkbox]") ]), m("td", "task description"), ]) ]) ]) ]); };
I think the idea is that it's simple — it's just a basic data structure in the language and can be generated or manipulated with just simple JavaScript. This is similar to why Lisp programs being Lisp data structures is interesting. Intriguingly, it looks like the API is compatible with React's JSX. With that, you could write this as: @jsx m todo.view = function(ctrl) { return ( Add Desk description ); }
That is ugly as heck - for some of the complaints that some people have with Angular's templating, it doesn't force you into tying your view so heavily to JS. That is far more of a travesty.
Re: Show HN: My new JavaScript MVC framework
#133I've become a huge fan of simple things. When I was just starting out developing software, I was a big fan of huge integrated solutions. But as the years went on I loved well scoped, lean options. This is the reason why I like Backbone.JS instead of Angular. The reason why I like Go instead of Java. Mithril looks really promising! Don't let feature creep turn it into a behemoth! Keep it lean and mean, and excel at th…
It's the power and pleasure of understanding. It makes your mental model of the project a closer approximation of omniscience. The cycle makes sense. A new programmer finds everything overwhelming, and the simplifications offered by something like Mithril often aren't enough to mitigate that feeling in any meaningful way. It's going to feel like you're drinking from a fire hydrant no matter what. But as you get a muc…
And how much net current/future amortized cost (time + maintenance + pain) / benefit there is between DIY & using "off-the-shelf" + learning/configuring/donkey-punching
Re: Show HN: My new JavaScript MVC framework
#134This is some pretty amazing code, actually. An MVC in 400 lines? Awesome. I could learn from this for days, lack of semicolons and one-line loops notwithstanding.
Re: Show HN: My new JavaScript MVC framework
#135Earlier quoted context omitted.
That's similar to my viewpoint. Stop with all the frameworks - what new, powerful functionality will it provide your users that existing things can't do (ie JQuery, raw JS)?
the point of a framework is speedy development. less lines of code for results. the tradeoff is often bloat, which one should (ideally) refactor out later. Angular can get overwhelmingly slow if you're not careful with your code, but gosh dang, you sure can whip an app up pretty fast
For most apps, I've found that slowness is not a problem with Angular. You can do some nasty things though if you're not careful though, definitely agree with that. If you have flaws elsewhere in your codebase, including the backend, it may be possible that in practice, the effects may trickle down to your frontend code with Angular - it has happened in an app I've worked on with a couple of other developers, in which flaws with the api performance caused us to implement some subpar workarounds that triggered many $digests & forced us to spend a day or two on just optimization.
Angular can be quite fast compared to jQuery in an app of substance. It is not constantly reading/writing to the DOM in most cases, which saves a lot on the performance front. It is also a smaller library than jQuery, and you're not naively applying global or complicated selectors. Plugins rewritten to be pure javascript + Angular also can have a much smaller footprint & be more powerful to boot, such as the Angular UI Bootstrap project (5 KB minified & gzipped as opposed to 15-35 KB? I forget Bootstrap's js size) & contains all of the power of Angular to modify your functionality with them & more.
Re: Show HN: My new JavaScript MVC framework
#136I've become a huge fan of simple things. When I was just starting out developing software, I was a big fan of huge integrated solutions. But as the years went on I loved well scoped, lean options. This is the reason why I like Backbone.JS instead of Angular. The reason why I like Go instead of Java. Mithril looks really promising! Don't let feature creep turn it into a behemoth! Keep it lean and mean, and excel at th…
I think this is the same taste-maturation that many woodworkers experience. At first, you salivate over these crazy, overly specific, over engineered power tools. Over time, you start to really love things that are stupidly simple instead, like a card scraper, or a hand plane.
Cooking is the same way.
A few, simple, fresh ingredients prepared quickly and correctly can be much more amazing than a complicated 20 ingredient recipe that takes 2 hours to prepare.
Re: Show HN: My new JavaScript MVC framework
#137Earlier quoted context omitted.
Nope, it's the truth. You can have JavaScript without the DOM in a Node.js or a CouchDB environment, for example.
I would say that what node.js runs is ecmascript with it's own API that differs from the DOM. It's called javascript for convenience, but then what separates javascript from ecmascript?
Nothing. It is only different in name. Oracle owns the actual copyright on JavaScript via Sun. ECMAscript was used so the ECMA would not have to worry about this.
Re: Show HN: My new JavaScript MVC framework
#138Earlier quoted context omitted.
How many times have you messed up a comma inside an array? And just for looping, this is literally constructing a web page out of it. There is no architectural benefit to this, all that's going to happen is that your going to fat finger some shit, and the compiler will complain to no end. Guys, rule of thumb, architecture === directory names. Performance is an implementation detail. Frameworks live and die by their A…
There's a sample TodoMVC posted here - https://github.com/jpmonette/todomvc-mithril . If you have any idea to improve, feel free to send a pull request!
https://github.com/jpmonette/todomvc-mithril/blob/master/js/...
Looks pretty painful, but I do think adapting JSX could be a pretty painless solution so I don't look at it as a deal breaker. I am still yet to find a javascript templating solution that I don't have at least 1 or 2 issues with.
Re: Show HN: My new JavaScript MVC framework
#139Earlier quoted context omitted.
I would say that what node.js runs is ecmascript with it's own API that differs from the DOM. It's called javascript for convenience, but then what separates javascript from ecmascript?
Nothing. It is only different in name. Oracle owns the actual copyright on JavaScript via Sun. ECMAscript was used so the ECMA would not have to worry about this.
I guess this is a point of contention. Javascript is considered by many to be an implementation of ECMAscript that also provides additional features (the additional features, according to the book I cited, being the DOM and BOM).
Re: Show HN: My new JavaScript MVC framework
#140[deleted]