61–70 of 138 posts
Shameless plug, but we did wrote an article outlining our experiences at https://blog.alarisprime.com/e-commerce-case-study-building-...
I really don't give a shit what anyone says, for me personally ReactJS makes front end great fun to program and an absolute blast and empowers me like never before to build powerful, interactive front end apps with a code base that is well structured, understandable and makes sense. Until React I dreaded front end development, painful, weird, quirky, hard to organise and generally problemtic. With React I feel like a…
-Two-way binding in all cases is slow
-Directives are unecessarily hard to write
-Angular's default DI model breaks on alpha conversion, the basis of every JS minifier ever. All the fixes are cumbersome.
-The system is poorly documented, making it hard for a dev to get started.
-The system is overly complex, slow, and hard to debug ($digest already in progress, anyone?).
-But most importantly, it implements stuff that has no buisiness being in an SPA web framework. It re-implements scoping, modules, part of JQuery, DI, and a programming language, complete with parser.
React, however, did the responsible thing, and stuck to a specific domain. Even if nothing else React did was good (and I have some arguments there), this is a major win over Angular.
But the claim and current consensus around web development is that "you should absolutely use a framework built by someone smarter than you or you'll end up shooting yourself in the foot" I find equally ill-informed.
Consider these popular libs and then consider how poorly they integrate with each other: jquery, bootstrap, require and knockout. If you are off by a version or two in jquery, then bootstrap will not work. Up the version of jquery and parts of your app will break down. Try to fit libs that aren't modularized or that use hard-coded deps with require. You'll end up rewriting those libs (to get rid of deps you don't need).
I feel javascript should be mature enough to use without frameworks. Remember the cutting-and-pasting of the javascript.com era? We're back to that, I feel. I mean, surely there are lots of smart snippets of code or even libs that you want to use in react but can't because the code-snippets or libs aren't following the react architecture. What do you do then? Cut-and-paste those parts that you need and that will fit into react, perhaps?
Earlier quoted context omitted.
I suggest replying with counterarguments, that will work much better than downvoting as I can clarify eventual misunderstandings.
If just everyone would do that - look through my comment history, there are hundreds of comments being downvoted heavily without any counterargument posted. HN is worse than reddit already.
This kind of shit is literally on the guidelines. Come on, just don't.
React is good for complex app desktop but not if you need performant and fast interface with 60 fps otherall in mobile. Last virtual dom like snabbdom preact and inferno are really fast also on mobile. And inferno and preact are compatible with react component. Vue.js 2.0 use an intelligent mixin of reactive data graph dependency and virtual dom separating the static and dynamics parts of template. Monkberry.js trans…
React is good for complex app desktop but not if you need performant and fast interface with 60 fps otherall in mobile. Last virtual dom like snabbdom preact and inferno are really fast also on mobile. And inferno and preact are compatible with react component. Vue.js 2.0 use an intelligent mixin of reactive data graph dependency and virtual dom separating the static and dynamics parts of template. Monkberry.js trans…
Mithril is also apparently really good at fast. But I've merely seen the benches.
Part of seems to be: "How dare people not like the tool I prefer", or simply that people don't want to be bothered to learn yet another JavaScript library (which I can understand, but I'm not being prevented from using the tools I like, just because React exists).
One "mistake" I see React make, others do too, is mixing JavaScript and HTML. I'm still firmly in the camp that believes in progressive enhancement as the correct way of developing for the web. React, Angular and most other modern libraries doesn't seem to share that view.
I see some point-missing arguments being made here. React isn't for scale. And it isn't to side step learning about html and css. It's main reason for existence is to make complex UIs easy to manage. Pretty much the only argument I can think of against React is that it's a boil-the-ocean system. Once you start doing your UI with it, you pretty much need to make the entire thing use react to really benefit from its mo…
In my experience React is quite ideal for cases where some parts of a site or an app need dynamic behavior. I'm currently working on an e-commerce platform's admin panel, and for us a complete rewrite would have been nearly impossible. With React we can keep the old HTML + jQuery codebase, and implement/refactor stuff as small or as big as we need (e.g. a live-search component or a whole new dashboard view). We're doing something very similar to this: https://github.com/reactjs/react-rails#rendering--mounting