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

My Reaction to React

pseudoconcurrentthought.wordpress.com

Post reply on HN
Print view View original

101–110 of 147 posts

Re: My Reaction to React

#101

Post by greggman »

m0dc wrote: post #77
brightball wrote: post #67

Earlier quoted context omitted.

100% agree on the common language front. The real challenge is when you're dealing with a language that has framework saturation, so there isn't really a "common" framework. Ruby and Python have Rails and Django which goes a LOOOOONG way in fixing this problem. Not many languages have that one, dominant framework and usually that's because people keep inventing new ones to deal with shortcomings of current ones OR th…

The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and m…

This seems to be what meteor is trying to be. A fullstack. Crossing my fingers. Some devs want to pick and choose. I just want it all decided. Let me get to my app.

Re: My Reaction to React

#102

Post by sotojuan »

FlyingSnake wrote: post #36

Thank you for writing this article. I'm an iOS/Backend developer looking to do some lightweight front-end programming, and whenever I look at the JS landscape I shudder. Nearly every suggestion from JS developers is on the line "Have you tried "React/Angular/Ember/ObscureJS?". The Grunt/Gulp/Yeoman/Bower/Npm/Batman.js etc toolchain makes me question my sanity. Is it so difficult to just use Plain Old JavaScript™ and…

Just pick one and get productive with it[1]. I recommend Ember, because it has strong conventions and just one tool (a CLI tool similar to Rails'). It uses a big toolchain underneath the hood but it's abstracted into one command.

[1] This is the important point. At the end of the day, no one cares what framework you use—whether your app works or not is what matters.

Re: My Reaction to React

#103

Post by brightball »

greggman wrote: post #101
m0dc wrote: post #77

Earlier quoted context omitted.

The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and m…

This seems to be what meteor is trying to be. A fullstack. Crossing my fingers. Some devs want to pick and choose. I just want it all decided. Let me get to my app.

Yep. Meteor is taking the flexible approach. With React taking the View only approach it makes it easier to just plug in with Meteor.

https://www.meteor.com/tutorials/react/creating-an-app

Re: My Reaction to React

#104

Post by moron4hire »

basch wrote: post #99
moron4hire wrote: post #76

Earlier quoted context omitted.

PHP was never explicitly designed.

semantics? php wasnt written to be a programming language. it was words written with an explicit purpose.

No, read the history of PHP. It started out as just a hack for a school assignment. It accumulated hacks to do different things over time. It didn't ever have an explicit design effort until way long after it had been adopted around the world and they decided they might try to make up for some of it's cruft.

Re: My Reaction to React

#105

Post by BurningFrog »

skewart wrote: post #9

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps…

OTOH, another common trap is to grab a framework for everything.

If you only need 2% of what a major framework offers, you are probably better off writing your own code that does exactly what you need.

"...and in the future, we can use all these other parts of the framework" is the mental error. This is YAGNI in minor disguise!

Re: My Reaction to React

#106

Post by reactwojsx »

undo76 wrote: post #64

Am I the only one that thinks that the author is trolling? I mean, the final code has obvious flaws: a) Difficult to read and mantain. (Compare with the version below). b) Inefficient in a real world scenario as it has to recreate the DOM every time the model changes. c) Difficult to test as it requires a DOM API. d) XSS issues (Text returned from the service is not escaped in the DOM!) e) Non isomorphic (Unless we h…

For those who don't know JSX, here's what it looks like in JavaScript (which might be easier to understand):

  const el = React.createElement.bind(React);
  const DATA = {    
    name: 'John Smith',
    imgURL: 'http://lorempixel.com/100/100/',
    hobbyList: ['coding', 'writing', 'skiing']
  };

  const App = ({ profileData }) => (
    el('div', {},
      el(Profile, { ...profileData }),
      el(Hobbies, { ...profileData })
    )
  );

  const Profile = ({ name, imgURL }) => (
    el('div', {},              
      el('h3', {name}),
      el('img', {src: imgURL})
    )
  );

  const Hobbies = ({ hobbyList }) => (
    el('div', {},
      el('h5', {}, 'My hobbies:'),
      el('ul', {},
        hobbyList.map((hobby, idx) => el('li', {key: idx}, 'hobby'))
      )
    )
  );

  ReactDOM.render(el(App, {profileData: DATA}), document.getElementById('content'));
The function el creates an element with the type as the first parameter, the attributes as the second parameter, and any child elements as the parameters after.

Re: My Reaction to React

#107

Post by k__ »

andreasklinger wrote: post #16
skewart wrote: post #9

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps…

imo: frameworks are materialized expectations given that software development is mainly about managing expectations this is of huge value

Yes, they are like forced coding style guides.

Re: My Reaction to React

#108

Post by Chris_Newton »

danbolt wrote: post #63
capkutay wrote: post #37

Earlier quoted context omitted.

This. If you are doing your own side project, building your own framework is a great way to sharpen your core software engineering skills. If you are architecting a product meant to scale, choosing a framework with significant mindshare, great documentation, and tons of learning materials and blogs supporting it is the right way to go. Frameworks are also supported by other frameworks. React/Redux has popular tools f…

The mindshare bit is an interesting one. I once read an article [1] that argued Lisp did not reach the same level of industrial popularity as other programming languages due to the fact that Lisp enables you to program in a lot of different ways for different reasons. I'm admittedly not very familiar with Lisp, and I don't know if I fully agree with the article, but it made me wonder if ease-of-collaboration can be c…

... it made me wonder if ease-of-collaboration can be considered a useful perk for languages/frameworks.

You could make a fair argument that ease of collaboration is the useful perk for the kinds of framework we’re discussing here.

In most cases, these frameworks don’t offer radical new functionality, but they do provide a focal point for developers interested in similar functionality.

Re: My Reaction to React

#109

Post by leeoniya »

jondubois wrote: post #48

I've tried most of the major frontend JavaScript frameworks. My favourite one is Google's Polymer framework - I like it specifically because it is very lightweight, easy to setup, easy to integrate into existing projects and it's ideal for building complex single-page apps. The best thing about Polymer is that, unlike React, it works with W3C standards instead of going off on a tangent and hacking the DOM entirely. I…

if you like declarative js-only templates and less monolithic/locked-in components, check out domvm [1]. disclaimer: mine.

[1] https://github.com/leeoniya/domvm

Re: My Reaction to React

#110

Post by m0dc »

sotojuan wrote: post #98
m0dc wrote: post #77

Earlier quoted context omitted.

The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and m…

Doesn't seem like it will ever be that way for React to be honest. If you want a JS monolith try Ember. Angular 2 may also be that way since it uses Ember's CLI tool.

I love Ember - and one of the best things about it is its emphasis on convention over configuration. React is the exact opposite. While it's an amazing library, it only makes up one part of a front-end stack, which causes everyone to waste tons of time deciding on what the other parts should be.

A set of sane, accepted defaults would help the community tremendously. Personally, I'm hopeful that that's what React/Redux/Webpack turns out to be.

Post reply on HN