111–120 of 236 posts
Earlier quoted context omitted.
Yeah, same. Can't give up JS/TS templating and typesafety. simply for a smaller size, I already use something that is way, way smaller than react.
I'm curious, what do you use?
> You can't write serious applications in vanilla JavaScript without hitting a complexity wall. This somewhat annoys me. You can definitely do it. Sure, it's easier, more comfortable, safer and quicker to use something like React. But you can still do some modularization that scales reasonably well without it. I've been working on an app and spent a lot of time looking into frameworks to handle its complexity but end…
Why are there complex MVC frameworks that run in the browser in the first place? I might get some flack for this, and I'm prepared for it, but why can't we use JS as just a view manipulator? Leave data processing and business logic to the back-end, on the server, and that can take care of needing a front-end framework and large app.
"Why waste energy doing stuff on your machines what you can get your users to do for you?" ...is the general reasoning. However, personally, I find that unless you're very well organised, you're not saving yourself much, if anything, in the long run.
Why are there complex MVC frameworks that run in the browser in the first place? I might get some flack for this, and I'm prepared for it, but why can't we use JS as just a view manipulator? Leave data processing and business logic to the back-end, on the server, and that can take care of needing a front-end framework and large app.
> You can't write serious applications in vanilla JavaScript without hitting a complexity wall. This somewhat annoys me. You can definitely do it. Sure, it's easier, more comfortable, safer and quicker to use something like React. But you can still do some modularization that scales reasonably well without it. I've been working on an app and spent a lot of time looking into frameworks to handle its complexity but end…
You can if everyone in the team is at least pretty good
How is this substantially different from Backbone/Marionette? I feel like we're regressing.
You only write your template once, you don't have to think about two separate paths: creation and update. With backbone, you either did that and had performance issues or did updates separately, which is a pain to maintain.
Also, in backbone, parentchild communication is a complete after thought.
Earlier quoted context omitted.
"the reason boilerplate bothers me so much is that it impacts the readability of my code" But if you hide boilerplate you not really improve readability. Not seeing what is really happening just creates the illusion of readability.
If the thing that I'm abstracting is routine, and unrelated to the business problem I'm solving, I don't need to know what's happening (at least in the sense of me or someone else coming back to read the code later). I don't need to know how an HTTP server, or the particulars of an AJAX request work most of the time.
> You can't write serious applications in vanilla JavaScript without hitting a complexity wall. This somewhat annoys me. You can definitely do it. Sure, it's easier, more comfortable, safer and quicker to use something like React. But you can still do some modularization that scales reasonably well without it. I've been working on an app and spent a lot of time looking into frameworks to handle its complexity but end…
You can if everyone in the team is at least pretty good
Love the ideas. I think now the community has settled on the Component based development, especially with JSX templates. What we need are multiple react-kernels implementations. I see React community providing component API specs. Similar to Linux distros, we should have API compatible implementations, where application code can run on multiple kernels without any changes. We are now seeing multiple react-shim layer…