Guide to JavaScript Frameworks • Hacker News Board

Re: Guide to JavaScript Frameworks

#241

Post by dsego » Fri, Jan 26, 2018, 6:43 PM UTC

mlsarecmg wrote: post #205

dsego wrote: post #94

Earlier quoted context omitted.

JSX is NOT just HTML and JavaScript! If it was just html I could write and not , I could write instead of . It's not even just javascript, or I would be able to write a simple if-else statement. JSX is a DSL, a minimal one, but still. I mean, you could say it's even worse, because those subtle differences can cost you hours of looking for mistakes.

> If it was just html I could write and not , I could write instead of for and class are reserved statements, hence htmlFor and className are the official api names, in other words they belong to the actual web-api spec, there's nothing arbitrary about it: https://developer.mozilla.org/en-US/docs/Web/API/Element/cla... https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl... If you really dislike it, you can s…

for and class are not reserved in HTML, they are in JS, but why would that matter for JSX?

Re: Guide to JavaScript Frameworks

#242

Post by pdm55 » Sat, Jan 27, 2018, 6:16 AM UTC

pdm55 wrote: post #240

https://jrsinclair.com/articles/2018/react-redux-javascript-...

That link was recommended to me as a simple, clear explanation of React. I'm a real minimalist - just plain vanilla Javascript serves my purposes - but I'm glad I read parts of that explanation, as I got familiarity with the term "render" and could see that React is the go-to framework for mobile.

Re: Guide to JavaScript Frameworks

#243

Post by mhale » Sat, Jan 27, 2018, 4:39 PM UTC

Ember is the PostgreSQL of JavaScript frameworks.

Similar to the way Postgres has deep roots that trace back to Ingres[1] in the days before SQL was a solidly established standard, Ember traces it roots back to SproutCore[2] in the JS framework pre-historic era of 2010.

And the same way PostgreSQL was seen as a second-tier or only "historically significant" open source database, the PostgreSQL team just kept at it, toiling away year after year, steading churning out awesome code and excellent documentation, getting better and better with each release. Like clockwork.

In the same way PostgreSQL is now, finally, enjoying more popularity and getting the recognition (long overdue in my opinion) for the awesome platform that it is, I expect that in time more developers will come around to appreciating Ember. The Ember leadership is definitely approaching the project and the processes around it like they intend to be not just relevant but pushing the boundaries for a long time to come.

For one example this boundary pushing, you should not miss @tomdale's talk at ReactConf about GlimmerJS (the view layer extracted from EmberJS). It is, in my humble opinion, simultaneously mind-blowing and and inspiring.[3]

[1] https://www.postgresql.org/about/history/ [2] http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor... [3] https://www.youtube.com/watch?v=nXCSloXZ-wc

Re: Guide to JavaScript Frameworks

#244

Post by mlsarecmg » Mon, Jan 29, 2018, 6:34 PM UTC

dsego wrote: post #241

mlsarecmg wrote: post #205

Earlier quoted context omitted.

> If it was just html I could write and not , I could write instead of for and class are reserved statements, hence htmlFor and className are the official api names, in other words they belong to the actual web-api spec, there's nothing arbitrary about it: https://developer.mozilla.org/en-US/docs/Web/API/Element/cla... https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl... If you really dislike it, you can s…

for and class are not reserved in HTML, they are in JS, but why would that matter for JSX?

    const { for, class } = this.props

Will crash. It's just a bit inconvenient (and inconsistent for beginners) having to write:

    const { for: forHtml, class: className } = this.props

Some react-like libs do allow it, but the dom api takes offcial precedence, so it's all fine. It's just that HTML in general was made without taking all the things into account we demand of it today. It wasn't even made for imperative inflating, so the dom-api faced the same troubles.