Tech specific. I wonder what Jeff might have to say on this? I know where I work neither React, Angular, nor Vue seem to quite fit our need; and I'm curious what other solutions might come out in the new tech industry that is beginning to turn over to DevOps type methodologies.
I'd say this was a pretty decent breakdown, though I don't really have any experience with Angular. Those were the two libraries I were considering when starting Readup from scratch and I ended up going with React and never looked back!
I like that React is just about the view layer only and doesn't try to do everything. In fact I don't use any of the other tools mentioned like Redux, React Router or Next.js. I also write everything in TypeScript and find that it works great with React and JSX.
Overall I just love the simplicity, both in the scope of what the library does and the unidirectional data binding, and the flexibility that comes along with it. I'm curious if you could touch on why none of those libraries fit the need at your company. I've heard that performance can become an issue if you're building a really graphically demanding UI but I've never run into anything like that so far with Readup.
I think for us it came down to 2 things; one, we were already sort of in the mode of creating everything in house. I'm new at the company, so I'm still guessing at what was going on over the last couple decades. It started in 95, almost died in 2009, and now is one of the leading digital document producers for mortgage transactions. That said, I think the second bit comes down to DOM; React looks like the better choice because it is faster and provides that layer of distance between trivial changes and the absolute back end. However, Angular in general appears like it would be more robust and fit better to our needs simply because of volume. But, then again, I suppose React can handle volume just fine and because of the architecture might better support client customization, which we do a LOT of.
I think perhaps the main catch might be the connection between the UI and what actually happens in the back end. The UI provides a lot of customization options for the clients and that changes how we process their docs in the back end. I don't know how these front end solutions would fit into such a configuration.
Tech specific. I wonder what Jeff might have to say on this? I know where I work neither React, Angular, nor Vue seem to quite fit our need; and I'm curious what other solutions might come out in the new tech industry that is beginning to turn over to DevOps type methodologies.
I'd say this was a pretty decent breakdown, though I don't really have any experience with Angular. Those were the two libraries I were considering when starting Readup from scratch and I ended up going with React and never looked back!
I like that React is just about the view layer only and doesn't try to do everything. In fact I don't use any of the other tools mentioned like Redux, React Router or Next.js. I also write everything in TypeScript and find that it works great with React and JSX.
Overall I just love the simplicity, both in the scope of what the library does and the unidirectional data binding, and the flexibility that comes along with it. I'm curious if you could touch on why none of those libraries fit the need at your company. I've heard that performance can become an issue if you're building a really graphically demanding UI but I've never run into anything like that so far with Readup.
I think for us it came down to 2 things; one, we were already sort of in the mode of creating everything in house. I'm new at the company, so I'm still guessing at what was going on over the last couple decades. It started in 95, almost died in 2009, and now is one of the leading digital document producers for mortgage transactions. That said, I think the second bit comes down to DOM; React looks like the better choice because it is faster and provides that layer of distance between trivial changes and the absolute back end. However, Angular in general appears like it would be more robust and fit better to our needs simply because of volume. But, then again, I suppose React can handle volume just fine and because of the architecture might better support client customization, which we do a LOT of. I think perhaps the main catch might be the connection between the UI and what actually happens in the back end. The UI provides a lot of customization options for the clients and that changes how we process their docs in the back end. I don't know how these front end solutions would fit into such a configuration.