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

71–80 of 157 posts

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

#71

Post by throw2016 »

The recurring pattern seems to be some new tech gets introduced, preferably by a well known SV company. Usually it matches their use case and is a struggle to adopt generically.

People scramble to learn it anticipating demand for jobs or contracts and become part of the hype cycle. If they can kick start the the cycle then everyone benefits and they are too vested to discuss quality, architecture, design or anything that risks the gravy train.

Things can become haphazard. Technical or complexity issues take a back seat and are hand waved away, apologism thrives. Discussion becomes heated as is wont when it comes to money.

There can be 100 articles like this about React but it won't matter. Because this is not about quality but economics. Even the most hardcore react fans know the ridiculousness of its setup is not tenable technically or otherwise.

Experienced people won't respond to fads and certainly not badly designed one as they have no need to. If the market for work was stable and less heated it would be much more difficult to pull off these hype cycles.

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

#72

Post by olavgg »

jasim wrote: post #56
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…

If your web-app has even a modicum of complexity on the client side, the vanilla DOM based solution is going to get unwieldy real fast. Consider a simple list of elements to which you can add or delete items. With vanilla DOM, you’ll have to write handlers that will `$.find` the particular element, and then run a `$.remove` to remove it. To insert something, you’ll have to do a manual `$.appendHTML`. And when you hav…

No adding/removing/modifying elements in a list is very simple and fast, even with thousands of elements.

Example: https://pastebin.com/Fu39i47z

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

#73

Post by olavgg »

amnah wrote: post #37
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…

Just curious, how do you handle the vanilla-JS stuff? 1) inline with your view files 2) write them in separate js files and include them depending on the page 3) concat them into one big js file which gets included on every page 4) something else?

Yes, we do a lot of inlining at the end of a view. In every case when the javascript is only usable for that view we find this very clean, every developer can immediately see what javascript is running on that particular view.

We have our own small library for the more common operations, for small things like more effecient navigating of the DOM three or more complex "components" that for example convert a select element to a nicer selectbox with built in full text search. That library is included for every view. This library weight around 50kb gzipped.

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

#74

Post by olavgg »

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.

We are creating a data management framework for AI-trainers, which are people creating data and analyzing data for our chatbot.

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

#75

Post by bollockitis »

wavefunction wrote: post #33
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…

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?

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

#76

Post by wand3r »

jazoom wrote: post #13
arenaninja wrote: post #8

I don't think the `className` argument sticks. `class` is reserved so you can't use it. It's annoying but not a difficult concept The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state? I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN…

It's valid. className was a frequent annoyance with React. That's one of the nice things about Vue. I can paste HTML snippets and they just work. I can't say it's the reason I switched, but it was some icing on the cake.

What was the reason?

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

#77

Post by olavgg »

rpedela wrote: post #42
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…

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.

Its more like that we needed to display A LOT of data, that you also needs to interact with, much more than you can fit in a screen. So we present this with a simple way to navigate this data by using simple pan and zoom operations! Our clients love this!

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

#78

Post by Bahamut »

arenaninja wrote: post #8

I don't think the `className` argument sticks. `class` is reserved so you can't use it. It's annoying but not a difficult concept The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state? I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN…

The className complaint is a valid complaint - it's a limitation of JSX, which is specific to React here.

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

#79

Post by thaiphanvevo »

wavefunction wrote: post #33
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…

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.

I have never heard anybody say that Angular 2+ is a joy to work with before. What about it do you like?

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

#80

Post by csallen »

olavgg wrote: post #72
jasim wrote: post #56

Earlier quoted context omitted.

If your web-app has even a modicum of complexity on the client side, the vanilla DOM based solution is going to get unwieldy real fast. Consider a simple list of elements to which you can add or delete items. With vanilla DOM, you’ll have to write handlers that will `$.find` the particular element, and then run a `$.remove` to remove it. To insert something, you’ll have to do a manual `$.appendHTML`. And when you hav…

No adding/removing/modifying elements in a list is very simple and fast, even with thousands of elements. Example: https://pastebin.com/Fu39i47z

jasim isn't complaining about performance, but about the complexity of the code.
Post reply on HN