121–130 of 167 posts
I'm a backend guy beginning to venture into front-end stuff (recently picked up JS for a Node project at work), and the extensive documentation is incredibly helpful for newcomers like myself.
PS: I'd be very interested in some performance comparisons with Om and Vue.
I don't mean this in a bad way, but do we really need another Javascript framework? Wouldn't author's energy be more useful when contributing to one of the existing ones?
That's the reason why I just shake my head every time I hear "HTML5 will overtake native for mobile apps anyday now". They still fight over what is the best MVC framework and have no idea what native offers. When did you last saw Android or iOS dev worried which MVC framework should they use, or maybe write their own?
With JS the restrictions and limitations of the system are different. People are coming up with creative and innovative ways to work with them. There's no problem with that, it a process that's ongoing in all software, and forever will be.
Also, "You" should really avoid using "They", especially when it applies to a broad group of people that you're making assumptions and judgements about. Maybe "You" have no idea what HTML5 apps offer (like portability)? I happen to think that html5 is going to be a major player in apps development, which puts me in your "They" camp, then again, I know what native offers - so I'm one of the many contradictions to your statement.
Hi, Mithril's author here. I'll just put a big comment here, and hopefully everyone can see it. @stronglikedan: I don't have plans for extending the core (in fact, keeping it small and modular is a major focus point for me). I do have a list of things I want to tackle next (see the roadmap page), but I'll most likely release them separately from core. @hcho: re: integrating w/ jQuery: see the integrating w/ other lib…
> thank you for the feedback, I really appreciate :) Well, thanks for the framework :) Apparently, you missed my (now deleted) question: > It would be nice if you could document the browser requirements. We're even, since I had missed the answer, which lies at the very end of the misc section of the documentation: > Mithril allows developers to support browsers all the way back to IE6 and Blackberry. Wow! This should…
Agreed! I'm in!
Here are my thoughts, but you won't like them. Stop with the frameworks. Learn Javascript. Learn CSS. Learn HTML. You'll find pretty quickly that what you need are libraries , not frameworks. Things like jQuery, underscore, etc...
A developer I worked with several companies ago told me the same type of thing about learning OO "Its not necessary just learn to code better". The fact of the matter is large code bases need to be supported over time by diverse groups of people and frameworks help enforce standards that get people up to speed quickly. That developer I knew, he has been chronically unemployed for the last 5 years because he lacks the…
The majority of the Web apps is CRUD + a bit of logic. It makes much more sense to use a framework because 1) most of the things are already there 2) easier to maintain for someone from outside 3) and, most importantly, very few developers have skills to create a nice, maintainable design, accompanied with a useful documentation.
Yes, in ideal world, maybe you should be able to stay framework-less (just made that word up) but the world isn't ideal. We have to sacrifice philosophical ideals for the business because that's what pays the living.
In rare cases, when the app is much more than a simple CRUD, it might make sense to ditch frameworks... But it's very, very rare.
Earlier quoted context omitted.
Are those things you wouldn't have to do under any other system, or which would be significantly simpler there? Because I'm not seeing it. You seem to be saying "This involves building a web page" — which is true, but would be regardless.
Yes, it would be simplificantly simpler to edit html if it wasn't stuck in between two strings, for one, let alone inside an array. todo.view = function(ctrl) { return m("html", [ m("body class='application", [ m("input class='add input input-sm input-md"), m("button class='btn btn-success button-green", "Add"), m("table class='table table-strped table-row", [ m("tr class='tr'", [ m("td", [ m("input[type=checkbox] cl…
Also, just FYI, the selector syntax follows CSS rules, so you'd write m("body.application"), not m("body class='application'")
Earlier quoted context omitted.
This is exactly why JSX is such a big win for this method of creating content - it's just sugar for the same function calls, but expressed in a form we're already used to multiply-nesting, with closing tags to help keep context and no need for commas when you need to break a line. Quite neat that you can use it for non-React stuff just by tweaking the pragma comment the JSX transformer requires. Here's an actual exam…
To be clear, my example wouldn't actually work. I had a brain fart about JSX's output format. Sorry about that. I do think it would be pretty easy to adapt it to this format, though (it looks like you'd just need to change one line in the visitReactTag() function).
```js / @jsx m.dom */
function m(type, props, children) { // assuming m() looks something like this. return { type: type, props: props, children: children}; } m.render = function(lwDOM){ console.log(lwDOM)}; m.dom = {};
// React hard codes this array so we can do something like this to build the mapping ['a', 'span'].forEach((el) => { m.dom[el] = function(props, ...args) { return m.call(null, el, props, args); } });
m.render( hello world ); ```
Here are my thoughts, but you won't like them. Stop with the frameworks. Learn Javascript. Learn CSS. Learn HTML. You'll find pretty quickly that what you need are libraries , not frameworks. Things like jQuery, underscore, etc...
Author of Vue.js here, I'm glad you included Vue in your framework comparisons. Here's some thoughts regarding your comments on Vue.js: the reason Vue chose to use ES5-only features is that it enables Vue to provide plain POJO syntax without having to resort to dirty checking or virtual DOM diffing. Granted the auto-magical POJO syntax is a somewhat leaky abstraction, but I'd argue that not all leaky abstractions are…
do you have a todomvc example :)
Earlier quoted context omitted.
While I admit I'm somewhat sympathetic to this reaction, it really is a cosmetic complaint. It's hardly uglier or more complex than ordinary html -- we're just used to html. Ofc there's some benefit to the technologies we're used to all things being equal, but I think architectural benefits trump concerns like this. I'm not making a case for or against Mithril, btw, just noting that this objection is a fairly surface…
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…