Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: My new JavaScript MVC framework

lhorie.github.io

Post reply on HN
Print view View original

111–120 of 167 posts

Re: Show HN: My new JavaScript MVC framework

#111

Post by nilkn »

sergiotapia wrote: post #10

I'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 much firmer grasp on the fundamentals, you also gain a much finer perception of bloat and cruft and what's necessary and what's not. So you feel a push to eliminate large all-encompassing libraries, because for the first time you realize that some sort of omniscience is within reach.

Re: Show HN: My new JavaScript MVC framework

#112

Post by julie1 »

iSnow wrote: post #93
Zelphyr wrote: post #36

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...

>Stop with the frameworks. >Things like jQuery, underscore, etc... Sounds great until you have a team of 5 developers maintaining at least a semi-huge code base over the course of some years. Some people leave, new join the team. Then you really start appreciating frameworks if only for their conventions to structure the code. Top coders can write web apps with jQuery and underscore alone, but everyone else is better…

HTML, css, JS (jquery) have stable APIs, when new developers come they don't have to learn something new.

If your code degrade over time, sorry to tell you, a framework won't solve the problem.

If you have coders that don't care about maintainability of code correction, code organization in whatever technology, they won't care about what you wish.

As usual, they won't take the time to learn the frameworks, will diverge, and you are back to square one with no code that can be salvaged or reused. (at least with vanilla techs you may salvage stuffs)

I think you use frameworks to solve the wrong problems here: you are probably the problem by trying to ditch the lack of real engineering skills in IT (not the letter of engineering. The spirit: making things that are correctly built and are reliable over time... like a plane).

Re: Show HN: My new JavaScript MVC framework

#114

Post by danneu »

ulisesrmzroche wrote: post #107
chc wrote: post #98

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…

    > Yes, it would be simplificantly simpler to edit html 
    > if it wasn't stuck in between two strings
    > ...
    > m("body class='application", ...
You would put attributes in an object.

    m("body", {class: "application"}, [ ... ])
Sure, it's no Lisp, but to me it's just Javascript's commas that suck the thunder out of it.

Re: Show HN: My new JavaScript MVC framework

#115

Post by julie1 »

killertypo wrote: post #82

just a bit of a nitpick, but your getting started page uses the word "performant" http://english.stackexchange.com/questions/38945/what-is-wro... the debate around the word just leaves a bad taste in my mouth. after reading arguments from both sides I would tend to agree: until the word is a word, it just sounds like marketing buzzword garbage.

it is a word in french ;)

It would translate to overperforming. Compared to what? No one knows. It is oddly very used as a buzzword in marketing.

If so (I could be wrong), maybe it is not marketing but "pardon my french" juste like "idiot savant", "touché" and other french words that appears in the mouth of some that wants to look smart: it make us laugh very hard as a mix of posture and failure.

Re: Show HN: My new JavaScript MVC framework

#116

Post by hmsimha »

nawitus wrote: post #77
JetSpiegel wrote: post #31

Earlier quoted context omitted.

It has reached the point where Javascript Framework coders don't know Javascript. Looks like Javascript IS the Assembly of the Web.

But DOM is separate from JavaScript.

DOM is separate from Ecmascript, but is actually one of the 3 components of Javascript (along with Ecmascript and the BOM). This is at least according to Professional Javascript for Web Developers (you can see it on 'page 3' in the Amazon preview).

Re: Show HN: My new JavaScript MVC framework

#117

Post by hmsimha »

nawitus wrote: post #92
JetSpiegel wrote: post #86

Earlier quoted context omitted.

Only theoretically. Javascript is a way to manipulate the DOM, no matter whan those nutters who run it on servers say.

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?

Re: Show HN: My new JavaScript MVC framework

#118

Post by insin »

danneu wrote: post #114
ulisesrmzroche wrote: post #107

Earlier quoted context omitted.

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…

> Yes, it would be simplificantly simpler to edit html > if it wasn't stuck in between two strings > ... > m("body class='application", ... You would put attributes in an object. m("body", {class: "application"}, [ ... ]) Sure, it's no Lisp, but to me it's just Javascript's commas that suck the thunder out of it.

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 example of a Bootstrap table in a React component using JSX: https://github.com/insin/lifequote/blob/master/src/component...

There's not much display logic in it, so it doesn't exhibit the usual progression I've seen when writing React components so far, in which most display logic happens up-front in a component's render() and often gets moved into another method and called directly from where it's going to go in the structure being returned from render(), so you generally don't end up with huge whacks of JSX in components which are doing more work.

Re: Show HN: My new JavaScript MVC framework

#119

Post by chc »

insin wrote: post #118
danneu wrote: post #114

Earlier quoted context omitted.

> Yes, it would be simplificantly simpler to edit html > if it wasn't stuck in between two strings > ... > m("body class='application", ... You would put attributes in an object. m("body", {class: "application"}, [ ... ]) Sure, it's no Lisp, but to me it's just Javascript's commas that suck the thunder out of it.

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).

Re: Show HN: My new JavaScript MVC framework

#120

Post by lhorie »

timmywil wrote: post #106
lhorie wrote: post #66

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…

You've missed the point. You're comparing MVC frameworks to jQuery as if that made sense, which it doesn't. As I said, Angular and Backbone use jQuery. So you're just comparing how you've used jQuery (as if that's how any jQuery user would do it) to how they've used jQuery. There is no such thing as "idiomatic" jQuery templating. There are only plugins and libraries that use jQuery to do templating. In fact, what you…

Many people are at a stage where they're using jQuery to build large apps and wondering what benefits a framework provides. Not having to worry about script injections is one of the benefits that frameworks bring to the table. This is a perfectly sensible thing to point out, imho, given both tools are used for the purpose of building web applications.

The technical implementation of the jQuery test is flawed on purpose, and that's the point. People make mistakes, some don't know better.

Are you arguing that every jQuery dev team in the world audits their code for stuff like:

  - bla.text(firstName + " " + lastName)
  + bla.html(firstName + " " + lastName) // bug fix 1234: make name not wrap
Or that somehow the jQuery community is gonna catch that in your application? Or that your innerHTML example (given a user-defined string) does not have a security hole? That you're gonna find that commit from the junior guy at 3am at crunch time? That "the developer should know better" is a good security strategy? Are you saying that one API that makes it hard to make mistakes not comparable to one that makes it easy to? That's the absurd claim, imho.

Like it or not, jQuery is the big elephant in the room, so yes, I'm going to compare to it, to the extent where it makes sense. Is it an apples to apples comparison? No. Neither is the comparison w/ React. But those comparisons are useful to some people, so I provide them.

Post reply on HN