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

My Reaction to React

pseudoconcurrentthought.wordpress.com

Post reply on HN
Print view View original

51–60 of 147 posts

Re: My Reaction to React

#51

Post by calahad »

iLoch wrote: post #11
adrianp wrote: post #8

Earlier quoted context omitted.

I'm not really fighting you on the merits of frameworks (which should be obvious to everyone), but are you implying that implementing a design pattern is equivalent to building a framework?

Not at all but what is the end goal of this if we consider that the code base will increase in size? You'd likely start adding more and more things to it to make it easier to work with and eventually you've unintentionally rolled your own framework. React could also still be implemented as part of the author's view because they haven't covered any of the problems with large cascading data updates. So there's literall…

He's not trying to make an argument against React. I take him at his word here, mostly because it was indeed helpful for me:

"If you want to use React, fine, I am not trying to convince anyone not to. I just want to show that components in a JavaScript application are quite simple to do and do not require any framework at all to do so."

There are a lot of less experienced web developers being steered towards react that can gain a lot by understanding what is being laid out here, whereas I think more advanced developers like yourself have so much assumed knowledge that its hard for you to see past what from your perspective are glaring differences/inadequacies in the approach he's taking in the article.

Re: My Reaction to React

#52

Post by norswap »

iLoch wrote: post #5

Okay I think the author is severely misinformed as to why we use React. I say this because the very first thing he says is to use MVC architecture and then goes on to write his own framework ( from scratch??????? ) ...Why? This solves none of the problems React was designed to solve and only makes things more complicated by introducing new APIs only you know. Yes, this approach with vanilla JS is great for small apps…

Your comment would probably carry more weight if you stated the problems React was designed to solve. It might not be clear to everyone.

Re: My Reaction to React

#53

Post by coldtea »

awjr wrote: post #29
adrianp wrote: post #8

Earlier quoted context omitted.

I'm not really fighting you on the merits of frameworks (which should be obvious to everyone), but are you implying that implementing a design pattern is equivalent to building a framework?

Is React a framework?

Yes. It frames how you work, with state, components etc. Besides, nearly everybody who uses React also uses Router and Flux, which make for a fuller framework.

Re: My Reaction to React

#54

Post by Wintamute »

Ugh. Aside from trivially simple projects trying to go framework-less just means you end up writing your own buggy unmaintainable franken-framework.

And look at those code examples in the article. Such a simple app, and yet already a confusing mass of IIFEs, module patterns and whatnot.

Framework churn is indeed tiring but throwing out what I would consider basic/essential tools of frontend (module bundling for starters) doesn't make sense.

Besides, React is a library for efficiently rendering large DOM trees ... so I'm not sure what point he's making by re-implementing an MVC framework?!

Re: My Reaction to React

#55

Post by Bahamut »

cies wrote: post #40
skewart wrote: post #9

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps…

I came here to say exactly this. I think that one thing to distinguish is: pick small yet popular libraries/frameworks that solve few and clearly defined problems and do that well. For comparison: I think React is (currently) still in the small category, I think Angular is waaay to big. This way you'll have tutorials, courses, books, stackexchange, educated talent, new features and bug fixes -- it all comes your way…

FWIW, Angular 2 will ultimately be a lot smaller than React - the Angular team seems to believe they can get the core library (similar to React in pure components, but allowing the user to access the AST itself for more flexibility for custom rendering engines for different platforms with less overhead) to under 10 KB minified & gzipped.

This is probably since the dependency injection, router, http, web worker, service worker, and testing modules will be properly split off at some point, as well as the polyfills. That leaves the necessary polyfills as zone.js (as of a couple of days ago a presented Stage 0 proposal), rx.js (the ES7 Observables proposal), reflect-metadata (ES7 decorator proposal), & an ES6 shim, and the necessary non-polyfill dependency of DI - all of these are pretty light.

Otherwise, I pretty much agree with the benefits of choosing a popular library/framework. The homebrewed HTML generation in the original article was quite painful to read, and if all someone is interested in is to figure out the HTML structure and how CSS interplays with it to style it appropriately, this pattern will fail fast. Angular, Ember, and React (or whatever popular/semi-popular library/framework) allow for much better template expression than this.

In addition, typing out all of that is tedious - repeating stuff like document.createElement every time will get old fast. One will then want to create a custom HTML rendering method that generates the appropriate DOM node depending on the string passed to the function. Then one will start trying to figure out optimizations since it turns out raw DOM generation/manipulation has surprising performance issues in some situations...at which point, one encounters what Angular 2, React, and virtual-dom have all encountered & largely solved. This doesn't even get into various other optimizations, such as using document.createDocumentFragment, creating a caching strategy, avoiding unnecessary node generation, etc., or writing the components such that they cannot be optimized by leveraging web workers.

It may be a fun academic exercise to create a rendering library, but in practice it is difficult to create a robust solution, especially one that works for a team. Doing a rough cost-benefit analysis, this path is seldom a fruitful use of one's time, unless one enjoys such forays & solving these problems.

Re: My Reaction to React

#56

Post by lisivka »

eddd wrote: post #45

I am no a JavaScript expert - I started playing with frontend (jQuery doesn't count) only recently. The only problem I have with your approach is that the model might mutate. For small projects it is ok - but for larger ones overriding state from many places generates pesky race conditions that are source of all evil. I am not advocating for react as well - to me it is just a view layer. Combining it with redux, flux…

Just use database at client side (e.g. PouchDB), which will solve your problems with concurrent modifications. Your Views will display data from DB. Your Controllers will put data into DB. Your DB will be Model. As bonus, PouchDB is able to replicate to CouchDB server without need to configure CouchDB at all (except CORS), which is superb for quick prototyping of real apps using clientside javascript only.

Re: My Reaction to React

#57

Post by sebastianconcpt »

andreasklinger wrote: post #16
skewart wrote: post #9

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps…

imo: frameworks are materialized expectations given that software development is mainly about managing expectations this is of huge value

Nice synthesis, you nailed it there

Re: My Reaction to React

#58

Post by ivanhoe »

iLoch wrote: post #11
adrianp wrote: post #8

Earlier quoted context omitted.

I'm not really fighting you on the merits of frameworks (which should be obvious to everyone), but are you implying that implementing a design pattern is equivalent to building a framework?

Not at all but what is the end goal of this if we consider that the code base will increase in size? You'd likely start adding more and more things to it to make it easier to work with and eventually you've unintentionally rolled your own framework. React could also still be implemented as part of the author's view because they haven't covered any of the problems with large cascading data updates. So there's literall…

Problem is that people use big frameworks even for cases where code base will not grow significantly in complexity (or even size). I believe that was the author's idea, not that React is bad in specific use cases that it handles, just that you need to make sure that you really will have the problem, before trying to solve it. For a lot of folks out there using react or angular is a form of premature optimization, and we all know what Donald Knuth used to say about it...

Re: My Reaction to React

#60

Post by mclovinit »

Only time I ever attempted something remotely similar was during a PoC using a specialized client device (think RF handheld) that needed to render content quickly in a custom browser. Loading tons of dependencies was my concern. So writing custom components with pure JS was the approach BUT those components were not for rendering views and instead for initializing behavior with regard to keypress behavior per view. Attempting to render content was still done with a server side templating framework (Thymeleaf). This was eventually abandoned because development and testing cross browser (on a PC) was buggy.

As many have already stated, a tutorial like this is interesting for hobby projects, but I would not adopt this approach in production. Libraries and frameworks have a lot of energy invested in them and should be considered early.

Post reply on HN