Live data from Hacker News

What I wish I knew about React

bitsofco.de

81–90 of 301 posts

Re: What I wish I knew about React

#81
post #17

Earlier quoted context omitted.

> It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app. This is why I stick with Vue. One tag later you're good to go, and all of the extra stuff (like .vue files) isn't necessary to use the framework. It's a godsend. I can't imagine how many hours I've lost to obscure webpack errors before switching.

You can, of course, do the same with React: https://reactjs.org/docs/add-react-to-a-website.html

But if one would lile to write in jsx, which is the default in react, the doc still guide you to use a preprocessor for production.

Re: What I wish I knew about React

#82

Earlier quoted context omitted.

Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.

I will never ever go back to the jQuery or vanilla js days. It might have been simpler (what ever that means) but the result was a nightmare to maintain and add to.

I’m prepared to go back as the developer I am today versus the developer I was before.

It’s almost like just when we’re ready to write some dope Jquery code, it’s time to go write in a new framework.

I can say for certain the best React code we will all write will be 5 years from now, but, it’ll be time to move on to the next one.

Re: What I wish I knew about React

#83
I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility.

And it's also constantly evolving and getting better. Just recently I started a React project with class components only to learn that hooks are now a thing and they remove a lot of boilerplate code. Even with redux, redux supports hooks as well so you can scrap that entire connect() stuff alltogether. Just back to simple function components.

Re: What I wish I knew about React

#85

Earlier quoted context omitted.

You seem to confuse "normal" with "required". dvt (correctly) states that "it's normal now to have like 3-4 compilation/transpilation" which is indeed true for most React codebases (open source and not) I've came across. In fact, I don't think I've come across a single React application that is seriously built without using JSX and without a bundler (like including react.js in the beginning of HTML). While not requir…

But what's so hard/bad? Literally zero config and two commands: npm install -g parcel-bundler parcel ./index.html

It adds complexity. Software rots faster. You are more likely to git clone a 7 year old front end project and be able to run it successfully than a 7 month old project. It’s hard to find projects that successfully pin versions down so that you can build them after regular work on them has stopped.

Re: What I wish I knew about React

#86
React is a framework though, not a library. I don't mean to be disparaging but this is an article about how someone thought react was one thing, found it was another and then wrote a post of random tidbits about things in react you could learn from its homepage?

Re: What I wish I knew about React

#87
post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

It’s the price of success. Similarly, a lot of people now vehemently hate Go, and in a few years they’ll be complaining about the problems with Rust. (No idea about frontend because as far as I’m concerned React is still on top.)

I don’t think it’s really too big of a deal, but I wish people would be more realistic and use less hyperbole. Everything has trade-offs, one’s own personal honey moon ending does not mean we were all blind and/or ignoring the faults with things.

Re: What I wish I knew about React

#88
post #8

(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior. "Everything an HTML tag" is an insane mantra…

I completely share your opinion here. I've had very little encounters with react but in those few 2 or 3 instances, I hated it with a passion. There are many things wrong with it. Some by design and over-engineering, some inherited from the garbage that is js to begin with.

* jsx: I've been very open about the utterly flawed notion that html should be treated as assembly or cobol: something that only old people with long white beards know and use. As a consequence you have to rely on post-market plug ins for your browser just to figure out where element X comes from. As opposed to what the "old people" would do: grep -rn {pattern} which will genuinely give you the answer in a few seconds tops even for even the largest of projects. As opposed to clicking your way through tons of elements in a browser and staring at a second screen to figure out which is which.

* The endless "compilation" just to get something show up on the screen. Not to mention the ridiculous amounts of system resources required to do said "compilation".

* 5-6mb js files. Holy crap!!!!!!!!!!!!!!!

* Everyone's obsession with mocking data. This is in all cases a terrible idea and leads to tons of "well it works on my machine". In essence you end up with two different applications, one being the frontend and one being the backend and you rely on getting everything right and magically turn that into a "they lived happily ever after". Well... That happens only in fairy tales. That's not to say you can't develop both in parallel without mocking data but for some reason I've hardly ever seen people do this.

IMO, the web is turning into a bigger mess than ever because of this. Even bigger than the flash and coldfusion days. IMO all of this needs to be scrapped and re-done. There have been plenty of attempts to replace js with something that is not garbage by design. But all those attempts were greeted with "No, U fragmentin DA web!!". Well yes, naturally. The point of a migration is to slowly ditch a horrible X for a better Y. Annoyingly, because of this, just like react, it seems js is here to stay.

A real shame really, given several much better alternatives. For instance, I used dart(pure, clean dart, no frameworks or anything) to build my personal page and while I still had to rely on transpiling, there's a strong type system which behaves as you'd expect and pure html and markdown. Yes, even for a simple thing, the generated js is 90kb gzipped but given it's entirely self-contained, no additional code needed and renders markdown out of the box, I'm fine with it. Is it ideal? Hell no. Can I add or remove stuff on the go if I ever need to? Absolutely. I may not be able to add an entirely new functionality while I'm hiking or whatever but add a link or something small and trivial without having to install a ton of crap or have a complex ci-cd setup?

1. vim a.html, add X.

2. git commit && git push.

And just like that, 15 seconds later I'm back to hiking. My argument here is that with some additional tweaks, things like these would be significantly more useful and manageable even for large projects than the huge lumps of fat that the "modern" frameworks enforce us to use.

Re: What I wish I knew about React

#89
post #55

Earlier quoted context omitted.

What kind of features require you to use react?

None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.

I sincerely think that dichotomy is not a useful one - that's not a choice you have to make. You can have server-rendered apps with significant interactivity (where it makes sense).

Many large websites still use server side rendering (in whatever language they want), and js to refresh data client-side as required and respond to user actions, pulling data from the server side. There is no need to attempt to move everything to client-side, it doesn't make the UX better IMO, sometimes it makes it worse.

Keeping most logic and templates server-side works just fine on large complex sites serving millions of people, and it's significantly simpler and more stable for development than react or other frameworks, which seem to be in a permanent state of flux.

Re: What I wish I knew about React

#90
post #71
post #19

Earlier quoted context omitted.

Classes in React are confusing because they aren't actually classes, just something shoehorned into classes. For example you wouldn't write your initialization code in the constructor, you would do it in componentDidMount. Classes in React generate false expectations.

Yeah but how is that different from any other UI framework? onCreate/onStart/onResume and onComponentDidMount, onPause/onStop/onDestroy and onComponentWillUnmount are basically the same. Be it Android, Swing, or Qt, everywhere it's the same pattern. React is the first framework which actually feels like UI development on the web, not anymore like JS spaghetti. In fact, having internal state, externally given props, e…

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.

You've been tricked into thinking you're using a class, but you're really not. I understand it's a useful trick, but hooks are more idiomatic for JS as a language.

As a side note, one of the problems with JS is that the community often disagrees about what JS is: https://babeljs.io/blog/2018/07/27/removing-babels-stage-pre...

Post reply on HN