5 ms·

Airbnb complains had some real issues. Udacity “problems” looks artificial. Animation Performance on old androids - and then agreed it’s non RN issue. Android

by maxdo 8y ago

Airbnb complains had some real issues. Udacity “problems” looks artificial. Animation Performance on old androids - and then agreed it’s non RN issue. Android SDK 26 playstore limits only NEW apps at first and react 0.56-RC support it, so plenty of time (4 month to adopt). Notch support was available before first devices hit the market. I believe here is different beast - programming language as a religion. One of my devs was really sabotaging processes just because he hate JS.

ko27 8y ago
The 4 months timeline (November) is for updates to existing apps not new apps. The new app limitation already goes next month into effect.
cyberbuff 8y ago
> Udacity “problems” looks artificial. Animation Performance on old androids - and then agreed it’s non RN issue. I think they specifically mentioned that some of the problems were not due to RN, it was their use cases.
tzahola 8y ago
>One of my devs was really sabotaging processes just because he hate JS. Did you fire him/her?
- illuminati1911 8y ago
  I hope they fired the people who thought using JS in 2017/2018 unless absolutely necessary is a good idea. Both Kotlin and Swift are extremely elegant and modern languages with awesome set of features while JS lacks fundamental things like type(s)afety and is filled with inconsistency errors/problems etc. And yeah yeah, JS is not complete garbage. I'm well aware of that, but there is no point bringing a broken knife into a gun fight.
  - coding123 8y ago
    That might be a perspective, our team uses typescript and we feel it's like bringing the army to a gun fight.
    - tzahola 8y ago
      The “gun” being which language?
  - sodafountan 8y ago
    Well, I guess going by your logic Microsoft should fire everyone busily writing Office365, Skype, Microsoft Teams, and Visual Studio Code in javascript. Also, type safety isn't a "fundamental thing" it's a design decision made by the creators of the language.
    - jayshua 8y ago
      It's certainly a language design decision, but as I've been using more powerful type systems I'm coming to the conclusion that not using a language with a good type system for any project intended to be maintainable in the long term is just bad engineering.
      - chrisco255 8y ago
        Type systems do nothing to save you from making unmaintainable code. How many awfully engineered, slow to iterate, legacy monolith systems with convoluted OOP architectures were built in Java or .NET? All that type safety was a mere crutch for deeply nesting state in 14 layers of inheritance. I've worked on enterprise systems that take 10x as long to ship a feature in than something like Node. Nevermind that it's easy to add types to JS these days if you really want them. How you architect a system and manage state (and how simple you keep it) has far bigger implications than types.
        filleduchaos 8y ago
        Yes, this is why TypeScript and Flow never got off the ground, and why PHP, Python and Ruby are all definitely not adding static type checking.
        chrisco255 8y ago
        Adding TS won't magically make your code base maintainable. TS/Flow are both successful, great projects for adding types. They help with tooling, and you spend less time inspecting the underlying code. But now you also have to maintain those types when things change. I work on a very large JS code base and the number of type errors I see is pretty rare. That being said, I'm not opposed to types. It's just not the panacea that people claim it is. Good tests and simple architectures will do more to make a code base maintainable than types will.
  - lazerwalker 8y ago
    If you disagree with someone over a technical decision, that's one thing. Assuming you're a professional software developer, I'd like to think at least once in your career you've managed to find common ground with someone who disagreed with you, and have realized that disagreements over e.g. programming language preference usually (even if not always :P) just mean that person's priorities differ from yours, rather than that they're incompetent. If you consciously produce poor work because you disagree with that technical decision, rather than either going along with it or finding more a more appropriate venue to express that disagreement, that belies an attitude that's seemingly at odds with being a member of a collaborative workplace.
anothergoogler 8y ago
> The load time when entering into the React Native portion of the app was longer than we would have liked. It often did not feel like a seamless transition. That is a "real issue." Frame it however you want, React Native is a compromise. Performance is a huge deal to users. It's not hard to tell when you're running one of these "one size fits all" apps.
LandR 8y ago
> One of my devs was really sabotaging processes just because he hate JS. To be fair, JS is a mess. Although if I was a dev and asked to write JS, I wouldn't sabotage stuff! Probably just leave and get another job. Seriously though, what do you mean by sabotaging stuff? What form did this take?
- sodafountan 8y ago
  But to be even fairer, JS has evolved into quite a nice language to work with over the last few years and I'd hope that developers who've used it in the past would take the time to re-evaluate it.
  - LandR 8y ago
    Has it? My last look at it was a year or so ago and it looked like a shit show I wouldnt want to touch with a barge pole.. Web front end and JS just seems like insanity. I don't know how anyone can use node... What would you recommend to someone averse to js to try and change their mind?
    - alangpierce 8y ago
      > What would you recommend to someone averse to js I guess it depends on what your concerns are: • If you're worried about too many libraries to pick from, I'd just go with the most popular ones. React is a pretty solid choice. • If you're worried about config being a pain, I'd recommend going with one of the starter tools like Create React App. Build tools are indeed a bit complex, but hopefully that's getting better over time. • If you're scared by lack of type safety or worried about language quirks, I'd recommend TypeScript. (Flow is also quite good.) In particular, TypeScript (and Flow) provides much more flexible static typing than I've used in any other mainstream language. You get the nice navigation, autocomplete, and static checking that you'd expect from a typed language, and I've found that I spend much less time needing to think about how to write my code in a way that appeases the type system. Here's a tutorial that hits all of the points above: https://github.com/Microsoft/TypeScript-React-Starter https://github.com/Microsoft/TypeScript-React-Starter

by maxdo 8y ago

ko27 8y ago

The 4 months timeline (November) is for updates to existing apps not new apps. The new app limitation already goes next month into effect.

cyberbuff 8y ago

> Udacity “problems” looks artificial. Animation Performance on old androids - and then agreed it’s non RN issue. I think they specifically mentioned that some of the problems were not due to RN, it was their use cases.

tzahola 8y ago

>One of my devs was really sabotaging processes just because he hate JS. Did you fire him/her?

illuminati1911 8y ago
I hope they fired the people who thought using JS in 2017/2018 unless absolutely necessary is a good idea. Both Kotlin and Swift are extremely elegant and modern languages with awesome set of features while JS lacks fundamental things like type(s)afety and is filled with inconsistency errors/problems etc. And yeah yeah, JS is not complete garbage. I'm well aware of that, but there is no point bringing a broken knife into a gun fight.
- coding123 8y ago
  That might be a perspective, our team uses typescript and we feel it's like bringing the army to a gun fight.
  - tzahola 8y ago
    The “gun” being which language?
- sodafountan 8y ago
  Well, I guess going by your logic Microsoft should fire everyone busily writing Office365, Skype, Microsoft Teams, and Visual Studio Code in javascript. Also, type safety isn't a "fundamental thing" it's a design decision made by the creators of the language.
  - jayshua 8y ago
    It's certainly a language design decision, but as I've been using more powerful type systems I'm coming to the conclusion that not using a language with a good type system for any project intended to be maintainable in the long term is just bad engineering.
    - chrisco255 8y ago
      Type systems do nothing to save you from making unmaintainable code. How many awfully engineered, slow to iterate, legacy monolith systems with convoluted OOP architectures were built in Java or .NET? All that type safety was a mere crutch for deeply nesting state in 14 layers of inheritance. I've worked on enterprise systems that take 10x as long to ship a feature in than something like Node. Nevermind that it's easy to add types to JS these days if you really want them. How you architect a system and manage state (and how simple you keep it) has far bigger implications than types.
      - filleduchaos 8y ago
        Yes, this is why TypeScript and Flow never got off the ground, and why PHP, Python and Ruby are all definitely not adding static type checking.
        chrisco255 8y ago
        Adding TS won't magically make your code base maintainable. TS/Flow are both successful, great projects for adding types. They help with tooling, and you spend less time inspecting the underlying code. But now you also have to maintain those types when things change. I work on a very large JS code base and the number of type errors I see is pretty rare. That being said, I'm not opposed to types. It's just not the panacea that people claim it is. Good tests and simple architectures will do more to make a code base maintainable than types will.
- lazerwalker 8y ago
  If you disagree with someone over a technical decision, that's one thing. Assuming you're a professional software developer, I'd like to think at least once in your career you've managed to find common ground with someone who disagreed with you, and have realized that disagreements over e.g. programming language preference usually (even if not always :P) just mean that person's priorities differ from yours, rather than that they're incompetent. If you consciously produce poor work because you disagree with that technical decision, rather than either going along with it or finding more a more appropriate venue to express that disagreement, that belies an attitude that's seemingly at odds with being a member of a collaborative workplace.

anothergoogler 8y ago

> The load time when entering into the React Native portion of the app was longer than we would have liked. It often did not feel like a seamless transition. That is a "real issue." Frame it however you want, React Native is a compromise. Performance is a huge deal to users. It's not hard to tell when you're running one of these "one size fits all" apps.

LandR 8y ago

> One of my devs was really sabotaging processes just because he hate JS. To be fair, JS is a mess. Although if I was a dev and asked to write JS, I wouldn't sabotage stuff! Probably just leave and get another job. Seriously though, what do you mean by sabotaging stuff? What form did this take?

sodafountan 8y ago
But to be even fairer, JS has evolved into quite a nice language to work with over the last few years and I'd hope that developers who've used it in the past would take the time to re-evaluate it.
- LandR 8y ago
  Has it? My last look at it was a year or so ago and it looked like a shit show I wouldnt want to touch with a barge pole.. Web front end and JS just seems like insanity. I don't know how anyone can use node... What would you recommend to someone averse to js to try and change their mind?
  - alangpierce 8y ago
    > What would you recommend to someone averse to js I guess it depends on what your concerns are: • If you're worried about too many libraries to pick from, I'd just go with the most popular ones. React is a pretty solid choice. • If you're worried about config being a pain, I'd recommend going with one of the starter tools like Create React App. Build tools are indeed a bit complex, but hopefully that's getting better over time. • If you're scared by lack of type safety or worried about language quirks, I'd recommend TypeScript. (Flow is also quite good.) In particular, TypeScript (and Flow) provides much more flexible static typing than I've used in any other mainstream language. You get the nice navigation, autocomplete, and static checking that you'd expect from a typed language, and I've found that I spend much less time needing to think about how to write my code in a way that appeases the type system. Here's a tutorial that hits all of the points above: https://github.com/Microsoft/TypeScript-React-Starter https://github.com/Microsoft/TypeScript-React-Starter