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

An experienced Javascript developer’s account of learning React

medium.com

Post reply on HN
Print view View original

111–120 of 157 posts

Re: An experienced Javascript developer’s account of learning React

#111

Post by jhedwards »

olavgg wrote: post #29

At our company, we have banned React, Angular and other "overengineered" JS frameworks. Our HTML is rendered from a standard boring Groovy server page, with some vanilla-js for DOM manipulations here and there. We have hired developers that were React fans, which quickly changed opinion that this old-school way for developing web applications is indeed better. It is faster to code, an order of magnitude easier to mai…

But how do you handle the encapsulation of views? If I am working on a React app and I want to add a new interface, say a simple view that displays a record and has some controls on the left side, I might write something like this:
This view would be injected into the frame of the app that already has a navbar and footer, the layout would be pre-built via my panel components Left and Right, and if I want to change the control-panel I can go to that file and make any changes I want so long as the API stays the same. Similarly, if the schema changes and we need to update the way we display records, I would go to the RecordView component and change it because it is a decoupled module. I just don't see how you can accomplish this with vanilla HTML and JS.

Re: An experienced Javascript developer’s account of learning React

#112

Post by AndrewNCarr »

autoreleasepool wrote: post #14

Regardless of these complaints, the job market for React is just too damn good to ignore. I bit the bullet and began learning. As a newbie, I understand the sentiment of this article. However, it's really not as bad as the author makes it out to be. Also, className instead of class took all of 3 seconds to learn.

className is a small inconvenience when porting over an existing app to react (e.g. pasting in existing html), as is the requirement for style parameters to be objects. className is a quick find replace, but style is a more lengthy transpose process.

These are small frictions, but in the same way that every ounce/gram counts to a hiker, minimizing process frictions makes a big difference in productivity during times you already have a high cognitive load.

Re: An experienced Javascript developer’s account of learning React

#113

Post by zepolen »

platz wrote: post #108
drdaeman wrote: post #105

Earlier quoted context omitted.

Oh, no, I'm sure that's incorrect. Templating libraries can't update documents, they can only overwrite them completely. This either loses state (entered-but-unsaved text, cursor positions, collapse status, etc.), or requires a lot of watchers and extra state information. Those DOM updates is the whole point of React. There are other libraries that work in a similar fashion, but React has more traction thus reusable…

no, the point of the template engine is not to push all the logic into the templates. as you say you still handle the state yourself. the template render just skips the messy output building step, which for many cases is all you need

I don't think you understand what OP is talking about.

Re: An experienced Javascript developer’s account of learning React

#114

Post by tps5 »

Achshar wrote: post #34
autoreleasepool wrote: post #21

Earlier quoted context omitted.

I don't see where the parent suggested no framework. It's likely he or she prefers working a different framework or library, like vue.js or even jQuery. For me, jQuery is the bare minimum requirement. I would never attempt to write a large app in pure JS, even with babel. You would definitely run into some of the problems you mentioned. EDIT: I see now where he mentioned no-framework JS

I have written relatively large (35k lines) project in pure JavaScript (without even jquery) and have never faced any of the issues mentioned by the parent, (Babel helped). I write native first and then run babel to appease my older browser faring users. The advantages of native are that it's extremely snappy to use and fast to load. Bears smaller memory footprint (have to use angular.js at work and god it's awful) a…

I have no idea what "native" means in this context, care to elaborate?

Re: An experienced Javascript developer’s account of learning React

#115

Post by virmundi »

bollockitis wrote: post #75
wavefunction wrote: post #33

Earlier quoted context omitted.

Angular/Angular4 is a joy to develop with, so that's too bad you're limiting yourselves artificially. We have groovy in my stack at work and everyone despises it. Fortunately that's a legacy we're moving away from.

Out of curiosity, what does everyone despise about Groovy?

It's not the new hotness anymore. Scala came along. The author of Groovey says Scalia is better. It's also semidynamic. So if you don't like that, you won't like that (tautology of the day).

Updated for Scalia to Scala.

Re: An experienced Javascript developer’s account of learning React

#116

Post by jasim »

valarauca1 wrote: post #107
csallen wrote: post #80

Earlier quoted context omitted.

jasim isn't complaining about performance, but about the complexity of the code.

Parent's paste bin is ~40 lines of code (with white space) consisting of 4 functions, with what? 4 loops. If you consider 40LOC complex I don't understand why you work as a dev.

> If you consider 40LOC complex I don't understand why you work as a dev.

Goodness, your snark that questions the parent's competence is not only unwarranted, it is based on an incomplete understanding of the value of abstractions in programming.

It is not about 40 lines of code, it is about a basic programming model that allows us to understand and create user interfaces irrespective of how complex or large it is. It lets you compose your UI based on a tree of state and pure functions. If you don't have this abstraction, you do not have a coherent programming model to build UIs.

Re: An experienced Javascript developer’s account of learning React

#117

Post by virmundi »

ckorhonen wrote: post #85

Switching to React definitely has a learning curve, especially if you are coming from old-stool JavaScript or just not used to some of the concepts in React or Redux themselves. That said, once you get your head around it things start falling into place. We're recently built a React Native app and I feel the benefits it brings to cross-platform development make that ramp-up worthwhile. A single iOS and Android codeba…

How much of your code is OS focused? When I tried other approaches such as Ionic, the views started to be come heavily OS focused. Do you just forgo the native appearance?

Re: An experienced Javascript developer’s account of learning React

#118

Post by [deleted] »

BjoernKW wrote: post #38
olavgg wrote: post #29

At our company, we have banned React, Angular and other "overengineered" JS frameworks. Our HTML is rendered from a standard boring Groovy server page, with some vanilla-js for DOM manipulations here and there. We have hired developers that were React fans, which quickly changed opinion that this old-school way for developing web applications is indeed better. It is faster to code, an order of magnitude easier to mai…

Might I ask what kind of applications you're developing? While I generally like the idea of doing web applications the old-fashioned way depending on the requirements manipulating the DOM using vanilla JavaScript can quickly get out of hand.

[deleted]

Re: An experienced Javascript developer’s account of learning React

#119

Post by clay_to_n »

sotojuan wrote: post #25
kasbah wrote: post #20

I am confused why people think Redux is complicated. Maybe you were trying to use React-Redux? Redux itself seems incredibly simple to me, so simple that I sometimes wonder if I need a library for the functionality at all. This "Redux in a nutshell" sums up the simplicity nicely I think: https://gist.github.com/MarcoWorms/30758235f05faec844b8c06ce...

I've had the same experience. It took me about a week to "get" Redux as a new-ish dev back a year or so ago. Why do you think people have trouble with it?

I think the different parts are confusing.

As a dev learning about it for the first time, "Action Creator", "Store", and "Reducer" don't mean anything. Is "Store" a database connection? "Reduce" sounds like functional programming, sounds hard. Why "Action Creator"? Aren't actions objects that I can create with "new"?

For me, I also didn't understand the value in splitting it into those pieces - when I was learning Redux, I kept wondering "why aren't these just pub / sub events? Can't you do this with an event bus?"

I think most devs aren't used to learning new high-level patterns. Most know MVC, maybe a couple others, but I think Flux / Redux are a bit more complicated (by nature) than that. I doubt anyone interested in Domain-Driven Design or Clean Architecture would have an issue picking Redux up, but those devs are the exception.

Re: An experienced Javascript developer’s account of learning React

#120

Post by mambodog »

This post is misleading throughout.

The article shows snippets from the Redux and React Router docs, implying they are realistic examples of the way that typical React code should look, however, they are clearly snippets which are trying to show the entirety of an API on one screen. If your code is just a bunch of snippets copy-pasted from docs without much thought given to the structure of your code, your choice of UI library isn't the problem.

On React Router, React Router is not React. You don't need to use React Router. There are plenty of stable pure JS routing libraries, which don't release new versions often (or ever, because they are 'done'). Nothing about React requires you to use a React-related routing library.

The author found Redux and MobX too complex for their use case. However, Redux and MobX are not required to use React (there seems to be a theme here), and probably not useful if you don't have a big single page app with a lot of client side state. Implying they are intrinsic aspects of using React is wrong.

The bits at the end:

you will need to import in your scripts react-dom and react without never using the last one instance for some wild reason known only by the React team

The react and react-dom packages are being split so react-native doesn't have to pull in dependencies which are only used on the web. Not that different to Rails splitting up into a bunch of gems.

you can render functional components just by using js functions but you will need to wrap all your markup always in a wrapper tag to properly allow the Virtual DOM creation

This was an architectural limitation which is going away in the next major version.

its apparent simplicity is hidden behind a whole toolchain you need to configure before you can even writing 1 line of code

Why complain about this but refuse to use create-react-app? It literally solves this problem.

I started my app with React 15.5.0 knowing that my code is deprecate before even starting because facebook has just announced that for the next major release they are planning a complete rewrite of the framework and this means that they will likely nuke the current source because it can be no longer maintained.

This is FUD. The team has said that the next version of React will have some small breaking changes, but the API will remain almost completely the same. Not sure what they mean by 'nuke the current source' though.

Post reply on HN