Hacker Newsnew | comments | show | ask | jobs | submit | EugeneOZ's comments login

Maybe intent was good, but some advices are harmful. For example, 1 and 7. While in general it's not lie, but they can lead to thoughts "eat everything you want, just try to eat more "healthy" things, and "don't go to screenings at all".

If you tell someone to be careful not to fall off the right side of a bridge, and they then run away and fall off the left side, does that mean your advice was harmful?

Just because someone might overreact doesn't mean you shouldn't warn them.


Good to see progress in this field. Also want to remind that you can use SIMD in Dart already now: https://www.dartlang.org/articles/simd/

In which browser?

None, until SIMD appears in JavaScript.

Which was the whole point of my question.

Dart has become just another language that transpiles to JavaScript, abandoned even by Googlers.


Google use it for the most mission-critical part of their business, I'm not sure it means "abandoned". http://news.dartlang.org/2015/03/dart-for-entire-web.html

And more: https://www.dartlang.org/community/who-uses-dart.html


That is not the image the Angular team has shown to the world.

What is the business value to use Dart instead of any other language that transpiles into JavaScript?


Angular 2 exists in 3 forms: TypeScript, Dart and ES5. And a lot of ideas came to ng2 from AngularDart.

> What is the business value to use Dart instead of any other language that transpiles into JavaScript?

It's the question of preferences. Dart gives great tooling (IDE, debugging, testing) and more advantaged language, but universe of Dart is much smaller, so there are pros and cons, as always. There is no one ideal size of shoes.


My understanding is that Dart is being used directly, just not in any mainstream browsers. I believe Google Fiber uses Dart for their set-top boxes, but there is also use internally at the company (i.e. intranet).

All details are in link, but tl;dr is "Not in browsers yet".

Dart or NodeJS (only for given requirements, not in general).

Well, in reality a lot of food delivery services are being served by people, who answer phone calls. Not very scalable way, but it works :)

There is a lot of good and even awesome things in ReactJS universe, except JSX. Thousands of developers took their lessons in PHP/Perl/Python about mixing logic and representation, and now in nightmares they will generate HTML from logic, especially by parts and in worst case - using conditional cases. Everybody who tried to change design of website, written using something like "if ($birthday) $html .= getBirthdayButton()", will understand me.

Maybe JS developers should go through it, through this circle of hell, to avoid it in future, so JSX is necessary evil.

//despite of that, I sincerely thankful for people behind React, for their new ideas and how they changed fields of JS frameworks and mobile apps. Big respect!


You might be confusing programming languages with concepts.

Don't think of React as "a container for logic and a system for doing views". Think of it solely as view logic.

It's not mixing views with program logic. It's only view. There's nothing to mix. It just happens --- wonderfully --- to use a real programming language to represent those views.

The notions of logic, controllers, models, storage, and all that jazz are why there's also Flux (or Backbone or whatever else it is you want to use; we use Flummox, it's fine).


You might be confusing "logic" and "business logic" terms, I talk about "logic" exactly. Any logic and conditional cases makes design very difficult to change, because you can't anymore just move one piece of HTML (tags) to another place, or replace all classes with ctrl+f - it becomes very complicated with logic used to build it.

In practice, it is extraordinarily easy to move a React component from one place in the UI to another, most especially if you're using Flux, so that components are decoupled.

That's been one of my favorite things about working with React: it actually works to design bottom-up, factoring low-level components out and then moving them around like cutouts.

I could not do things like that in Knockout, or, god forbid, Mustache and server-side templates; not without changing the application logic to account for the move.


Components are made for code reuse - of course it should be easy to move them :) They are encapsulated.

I get the feeling that you're just arguing for the sake of arguing. You can't in one comment say that it's hard to move things around and then in the other comment say that of course it's not hard to move things around.

Maybe if you will read my comments more closely you will see the difference between moving parts of HTML inside component and moving components. "Moving things around" is too broad term.

The distinction you're making between "HTML" and "facility for encapsulating generated HTML" seems pretty arbitrary.

I was making a simpler point, though.

Some of the reactions I see to React seem to come from the notion that it's mixing application logic with view logic. That's an easy misconception to get from reading the tutorials and quick-start documentation: after all, it's using raw Javascript to generate HTML, which is the same language other frameworks use for application logic.

The misconception comes I think from comparing React to Angular. Angular is an application framework. React is solely a view framework. It happens that React uses Javascript --- which works amazingly well in practice! --- to express views. But that doesn't mean it's mixing application logic and view logic.

That's all I was saying. The semantic argument between "components" and "HTML" is totally uninteresting to me. The important point, regarding ease of moving "bits of UI" around, is that React makes it astonishingly easy to do that. It's one of the selling points of React.


In my first response to you I underlined I don't mean business logic.

It's the example from "JSX in Depth" (https://facebook.github.io/react/docs/jsx-in-depth.html)

  // Input (JSX):
  var content = <Container>{window.isLoggedIn ? <Nav /> : <Login />}</Container>;
  // Output (JS):
  var content = React.createElement(
    Container,
    null,
    window.isLoggedIn ? React.createElement(Nav) : React.createElement(Login) );
And it illustrates exactly what I'm trying to say: composing page from JS with conditional logic. It's plague, because it will be painful to edit.

I find it vastly, comically easier to edit React/JSX than templated Angular and Knockout.

This is the first thing every dev says when he/she first discovers React.

Logic and representation are not two unrelated pieces to keep them separate.


If you don't know yet reasons to keep them separate, please google about it before arguing without arguments. For example, read about Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns

//You can use "they" to replace "he/she".


Separation of concerns and separation of technologies are a different thing. It would appear you haven't done your research. See Pete Hunt's famous talk:

https://www.youtube.com/watch?v=x7cQ3mrcKaY


Hm.. I didn't say a word about separation of technologies. If you have one non-broken piece of HTML and related piece of JS to make it "live" - it's one thing. If you use JS/php/python/ruby/lua/whatever to generate HTML, composing it by small pieces into one (inside one component) - it's another thing and it's exactly what I'm talking about.

You are just throwing unrelated links around. Parent's point was that in this case, logic and representation are one and the same concern. What you're doing is similar to using SoC to defend having to split up class definitions into .h and .cpp files.

Don't put your words into my mouth with "allegories", I hate it. I don't talk about cpp and headers at all, I talk about view templates and view logic.

You are using your gut feeling, but that's not how React works at all.

JSX is not HTML, mixing logic/presentation is not a concern because you're not dividing your rendering between backend/frontend, and finally you don't even have to care about the final HTML representation of your component, it's just an implementation detail.

Finally, it's all declarative since you're never modifying a DOM tree - and declarative is a pre-requisite for good UI frameworks.


I use my years of experience, I don't need gut feeling for it. I really don't talk about backend, absolutely. While we have "createElement", we will use it with conditional cases and as result we will have mess of NOT-BUSINESS-logic and HTML code.

If you're using createElement you're doing it wrong.

Exactly! It's shortest version of what I think about JSX.

I am playing around with React and if you want to keep it JSscripty (being the only dev who actually likes JS) or you want to use coffee script then createElement isn't actually horrible to use.

Especially not if you make an alias to ce or something like that.


if you want the best of both worlds, i use cjsx (https://github.com/jsdf/coffee-react) for my react components e.g. https://github.com/Azerothian/reacta-test/blob/master/react/...

I thought JSX was just a cosmetic overlay to regular JavaScript functions. I'm not a react expert but I'm pretty sure `return <div>whatever</div>` just returns an object with a property of div and value of whatever. Exactly the same as writing `return React.DOM.div(null, whatever)` or whatever the vanilla version is.

Pretty cool name with good connotations (like Bob Marley's music).

Congrats! Thanks to all who worked on it!

It's not a generalization but absolutely truth about all people who don't use password managers. They use same password for multiple accounts or invent some "complex" rule to create passwords by url or title or something else. And second option is in light years away from secure way of storing passwords :)

This article is difficult to read in original (for native speaker) too. Just raw flow of minds, without any shape.

They know only 1 part of the bridge, but without second part is not the bridge, but shameful biased grunt "oh oh, will we still make money on C++ or we need to learn something new to keep our income?". And question is answered before they company existed. They even dare enough to recommend others don't learn Rust in favor of C++ - so biased recommendation makes whole grunt even more pointless.

Don't get me wrong, I understand difference between constructive criticism and biased grunt of grumpy C++ programmer.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: