6 ms·

> If you opt-in for a flux architecture, you will > soon write Java-as-in-the-90 on the frontend > instead of Javascript, with so many adapters > and desi

by lhnz 9y ago

> If you opt-in for a flux architecture, you will > soon write Java-as-in-the-90 on the frontend > instead of Javascript, with so many adapters > and design patterns as layers you will become angry. That's not necessary. It depends where you're working. I agree that teaching the complete stack is a pain. I guess there is `create-react-app` to help you there, but its scope is very small: you're not going to get static typing for example.

dullgiulio 9y ago
My biggest problem is "the complete stack." Which one? How many months will it be the blessed way of doing things? As soon as I get some work outsourced, here it comes yet another build system and yet another complete stack I have to get expert at. Javascript lacks a standard library (a mistake from the beginning) as well as standard tools (can't blame Netscape for this, but today we could totally come up with something more definitive.
- tonyedgecombe 9y ago
  If JavaScript had a standard library from the beginning we would be replacing it now because it wouldn't support Unicode or promises or async or whatever is coming next.
  - sametmax 9y ago
    The stdlib can evolve with the W3C the same way the language evolves.
    - tonyedgecombe 9y ago
      You mean we're stuck with the legacy stuff forever.
    - hajile 9y ago
      The w3c cannot break the web. Once something is in the language a certain way, it stays (technically, there have been a couple small breaking changes, but the fact that you don't hear about them speaks to their size and impact)
- veeti 9y ago
  There is no single blessed "complete stack" for React and there never will be. That is a feature, since it is a view library only. It sounds like you're looking for a full framework, e.g. Angular or Ember.
- lhnz 9y ago
  React was released in 2013. Redux was released in 2015. If you'd picked them then you've had a very long amount of time using the same tools.
  - yellowapple 9y ago
    I'd hardly call 4 and 2 years (respectively) a "very long time".
    - type0 9y ago
      It is a very long time in js world of things
  - saint_fiasco 9y ago
    We don't have precognition. It is not safe to pick a brand new framework for an important project right away, we have to wait a bit first to make sure it is being maintained well.
sametmax 9y ago
Well, if you want routing, you need a provider, and if you want to pass your store to a component, you need a container, and if you want to react to store change, you need a reducer, and if you want to make async action with your store... There is an "-er" somewhere at every step. You pass callbacks here and props there, and then reference them the other way around. And then you plug stuff in your componentWillReceiveProps, or is it in compomentWillMount or componentDefinitlyDidMountISwear ? But wait this is a new style class, so you have to call super(props) in constructor insteat of getInitialState unless you have a super Esx plugin but then remember that your onClick callback need to rebind this otherwise you'll get 'attributeOnThis' is undefined somewhere in your bundle and you'll have a fun time. When you come from flask, Django or Ror, having to deal with such API feels like going back to before the 2000 bubbles, where corporates tried to port their knowledge to the Web. It does not feel agile at all.
- lhnz 9y ago
  I'm sorry but a `reducer` isn't a 90s-era Java concept at all [0], and you don't actually need to use any of those other things. This is beyond ridiculous. [0] https://en.wikipedia.org/wiki/Fold_(higher-order_function) https://en.wikipedia.org/wiki/Fold_(higher-order_function)
  - w4tson 9y ago
    No but writing HTML directly in your class is soooo late 90s like when we used to write Java Servlets! All this has happened before. It will happen again
    - hajile 9y ago
      You write syntactic sugar <div className="foo">abc</div> to turn into React.createElement('div', {className:'foo'}, 'abc') which generates an object {...stuff, tag: 'div', attrs: {className: 'foo'}, children: 'abc'}. Your final object is then compared to the previous object and any differences are manually written to the DOM in an efficient order. Hardly comparable to Java Servlets.
- 9y ago

by lhnz 9y ago

dullgiulio 9y ago

My biggest problem is "the complete stack." Which one? How many months will it be the blessed way of doing things? As soon as I get some work outsourced, here it comes yet another build system and yet another complete stack I have to get expert at. Javascript lacks a standard library (a mistake from the beginning) as well as standard tools (can't blame Netscape for this, but today we could totally come up with something more definitive.

tonyedgecombe 9y ago
If JavaScript had a standard library from the beginning we would be replacing it now because it wouldn't support Unicode or promises or async or whatever is coming next.
- sametmax 9y ago
  The stdlib can evolve with the W3C the same way the language evolves.
  - tonyedgecombe 9y ago
    You mean we're stuck with the legacy stuff forever.
  - hajile 9y ago
    The w3c cannot break the web. Once something is in the language a certain way, it stays (technically, there have been a couple small breaking changes, but the fact that you don't hear about them speaks to their size and impact)
veeti 9y ago
There is no single blessed "complete stack" for React and there never will be. That is a feature, since it is a view library only. It sounds like you're looking for a full framework, e.g. Angular or Ember.
lhnz 9y ago
React was released in 2013. Redux was released in 2015. If you'd picked them then you've had a very long amount of time using the same tools.
- yellowapple 9y ago
  I'd hardly call 4 and 2 years (respectively) a "very long time".
  - type0 9y ago
    It is a very long time in js world of things
- saint_fiasco 9y ago
  We don't have precognition. It is not safe to pick a brand new framework for an important project right away, we have to wait a bit first to make sure it is being maintained well.

sametmax 9y ago

Well, if you want routing, you need a provider, and if you want to pass your store to a component, you need a container, and if you want to react to store change, you need a reducer, and if you want to make async action with your store... There is an "-er" somewhere at every step. You pass callbacks here and props there, and then reference them the other way around. And then you plug stuff in your componentWillReceiveProps, or is it in compomentWillMount or componentDefinitlyDidMountISwear ? But wait this is a new style class, so you have to call super(props) in constructor insteat of getInitialState unless you have a super Esx plugin but then remember that your onClick callback need to rebind this otherwise you'll get 'attributeOnThis' is undefined somewhere in your bundle and you'll have a fun time. When you come from flask, Django or Ror, having to deal with such API feels like going back to before the 2000 bubbles, where corporates tried to port their knowledge to the Web. It does not feel agile at all.

lhnz 9y ago
I'm sorry but a `reducer` isn't a 90s-era Java concept at all [0], and you don't actually need to use any of those other things. This is beyond ridiculous. [0] https://en.wikipedia.org/wiki/Fold_(higher-order_function) https://en.wikipedia.org/wiki/Fold_(higher-order_function)
- w4tson 9y ago
  No but writing HTML directly in your class is soooo late 90s like when we used to write Java Servlets! All this has happened before. It will happen again
  - hajile 9y ago
    You write syntactic sugar <div className="foo">abc</div> to turn into React.createElement('div', {className:'foo'}, 'abc') which generates an object {...stuff, tag: 'div', attrs: {className: 'foo'}, children: 'abc'}. Your final object is then compared to the previous object and any differences are manually written to the DOM in an efficient order. Hardly comparable to Java Servlets.
9y ago