Live data from Hacker News

An experienced Javascript developer’s account of learning React

medium.com

41–50 of 157 posts

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

#41
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…

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.

But is it joy for customers to use the stuff you wrote in it? So many of these opinions always focus on the developers having fun instead of wondering what experience is for the user and maintainers.

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

#42
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…

React is for complex/dynamic UIs. By using canvas, you kind of admitted that the old-school way isn't good enough for that case. Having said that, if canvas works and is better than React for your case, then great! Use whatever works.

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

#43

Earlier quoted context omitted.

I dislike being the guy who things that 'everything sucks' but the things I've seen come out of React have been horrifying. Very few websites even require anything that React provides nor do most webapps need to be webapps. I've come across bugs where simple text boxes were crashing the browser. Fixing that bug took the front end three days because they simply had no idea how to fix it because everything was buried i…

Sounds like a case of bad developers. Obviously, plenty of sites that use React do just fine. That said, I've had those frustrations at work and wishing in my head that our SPA was a server-rendered app instead.

Sure, but the question that always lingered in my head was, how it even possible to mess up a text box? It was a simple input form that crashed the browser by taking up all its memory. I could literally see my browser GC spike during every single keystroke.

If it's possible screw up the most basic element of a website, I shudder to think what other simple elements are out there that are horribly written

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

#44

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.

Also `class` is a reserved word in JavaScript, author doesn't even notice this.

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

#45
Exactly my experience, but with Angular 2+ instead of React.

To me, in comparison with Vue.js, both of these frameworks are grossly over engineered.

I'm keeping a list of things that are, in my opinion, unnecessary or badly designed in Angular 2+. After around two days of hacking I have seven position and the list will probably keep growing.

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

#46
post #31
post #2

React popularity seems to me the result of wrongly-headed thinking: that because facebook is popular, any technology behind it must be good, and because react is popular (allegedly), react must be good. I've always been very sceptical of react, and I'm glad I didn't invest too much time looking into it, as it seems both a time sink and a boilerplate-filled approach. I wonder why some people like it, writing no-framew…

>writing no-framework javascript isn't difficult at all, If anyone recommends this without any concrete source code to illustrate the superiority of the advice, be skeptical for 2 reasons: 1) the programmer who rejects frameworks ends up writing another invisible framework that doesn't happen to have a name . Because the author is intimately familiar with his own code, he many not even realize that an implied framewo…

Imagine if I flipped around your statement and said - don't trust anyone who recommends the superiority of a framework without comparing absolutely every possible framework at their disposal and showing sample code to explain why a certain framework must be chosen. Are you up to this comparison task? Suddenly, the problem changes from "finding better tools for my job" to "evaluating some fairly opinionated peoples' views on how the rest of the world should write their code". The second scenario is best avoided because

a) you don't want to take the word of someone who isn't going to face the consequences of all your framework-induced overcomplicated code razzmatazz

b) for too many people, this also means skipping the part where they learn to walk and start trying to run

c) not to mention, the companies creating these frameworks are surreptitiously doing everything possible to change the nature of the web, so by not using the frameworks (however "open" the "source" is presumed to be), you register a little bit of a protest at a fairly low cost

Besides, have you ever considered the following: the person creating the invisible framework is actually best suited to find better ways, assuming they do want to improve their coding abilities. Such a person is more likely to naturally gravitate towards the solution. If they fail to do so, those who end up maintaining such code will end up gravitating towards the best solution. How do you think the converse scenario plays out, where someone did use a framework without really needing it, and then it was found to be overcomplicated and unmaintainable?

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

#48
post #22

Earlier quoted context omitted.

You can have complex logic and functions in JSX but that doesn't mean that you have to, so the example is very contrived. That way of writing the code is completely discouraged in the documentation and I haven't run across it often or at all in the real world.

The example in the article was lifted from the front page of the official React website [0]. [0] https://facebook.github.io/react/

It wasn't lifted from the docs. The tutorial is a tic-tac-toe game, while the example in the post is an AddTodo function [edit: there appears to be an add todo section, but the code is completely different]. Furthermore, all the examples in the tutorials show a pattern where you reference functions instead of writing them inside JSX.

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

#49
post #48

Earlier quoted context omitted.

The example in the article was lifted from the front page of the official React website [0]. [0] https://facebook.github.io/react/

It wasn't lifted from the docs. The tutorial is a tic-tac-toe game, while the example in the post is an AddTodo function [edit: there appears to be an add todo section, but the code is completely different]. Furthermore, all the examples in the tutorials show a pattern where you reference functions instead of writing them inside JSX.

Check again. On the homepage scroll down to:

> An Application

" Using props and state, we can put together a small Todo application. This example uses state to track the current list of items as well as the text that the user has entered. Although event handlers appear to be rendered inline, they will be collected and implemented using event delegation. "

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

#50

Why is mixing HTML into your code in PHP bad? Because it mixes presentation and logic. Why is mixing HTML into your code in React good? Because it isolates all the view code for a single component in a single file.

In his example in the pre-preface there was quite a big amount of logic.. I don't really see the point in your post looking at that code.

I thought that was irony, nuanced by a sly dig at Facebook.

The gist being that React is what happens when a PHP shop creates a client-side framework, with all the architectural warts that this might imply, if you're on the PHP-lowers-the-bar-to-web-programming-too-far bandwagon.

(FB engineers would probably tell you that their variant, Hack, is a far cry from PHP, and their coding standards are well above that of your bargain-basement wordpress drudge, but you get the idea)

Post reply on HN