9 ms·

Why I’m throwing out React and going back to Angular 1.x

51 points by swalsh 10y ago

jennytodavchych 10y ago
Yea, here is also one good article where you can read about both https://thinkmobiles.com/blog/angular-vs-react/ https://thinkmobiles.com/blog/angular-vs-react/
sreyaNotfilc 10y ago
The big issue with the author is having the time to build something. I wouldn't necessarily have chosen one framework/language over the other. The reason why is the author's current level of proficiency for building something that he wants. For example, if he was an ace at Assembly (instead of familiar with Angular) he could've easily wrote an article titled "Why I'm throwing out Angular 1.x and going back to Assembly". Its all relative. Some people can afford having the "most beautiful code", but that also goes with a budget and a group of people who can make it work (e.g. Steve Jobs ordering beautiful code/engineering for the Macintosh). I would say the most logical route would be to "Build the Damn Thing". Facebook used that notion, got the product out, got ahead, and now can afford sound code. Heck, Zuckerberg doesn't even code on Facebook's source anymore. No one (besides us engineers) knows or cares what Facebook is running on. Same with many other productions (not only software) out there (when was the last time we cared exactly how an Oreo cookie was made?). So to answer Steve's question "What am I supposed to do?", I would say "Just Do It! Make the product.". Do the work and live the dream (Same with all of us dreamers).
- sdflkd 10y ago
  > No one (besides us engineers) knows or cares what Facebook is running on. Same with many other productions (not only software) out there (when was the last time we cared exactly how an Oreo cookie was made?). Except for the people that complain about performance?
  - tracker1 10y ago
    I tend to complain more about interactive state issues, Redux (or other flux-like options) helps a lot there. Performance is usually a little further down, unless it's many seconds for response. Lately every time I see weird state management issues it's almost always an angular app. And depending on what you're doing, that can be outright exceedingly painful in Angular 1.
raspasov 10y ago
It comes down to what you are most experienced and familiar with. Choosing based on that is fine, but you have to realize that might be a very bad decision mid or long term. The author seems to be aware of that so all is good. It took a few somewhat successful projects gone wrong for me to learn to prefer objectively simpler techogies technologies even if it takes extra few weeks to start. But if your hard budget deadline is literally within weeks it makes sense to prioritize fast, familiar and easy.
notliketherest 10y ago
This guy makes his situation sound pretty fucking dire and then blames react for slowing him down? It takes awhile to learn any new technology. So he goes with what he knows. How is this React's problem? I worked with React for a year and know well enough to get a brand new app up in less than a day. So it'd make sense for me to choose React. I don't understand why this guy is blaming React.
- kerryritter 10y ago
  I am also a React fan but phrases like "I worked with React for a year and know well enough to get a brand new app up in less than a day" make me kind of sad. The cost just to get up and running with a JS framework these days is kind of painful. CLIs are doing a decent job resolving this, though.
  - headcanon 10y ago
    With create-react-app, it takes less than a few seconds, if you're fine with their defaults. If you need to mess with the webpack config it will take a bit longer but once you do it the first time its not a big deal. Putting everything together from scratch would take awhile, but that's the tradeoff of having a really flexible modular system.
    - franzpeterfolz 10y ago
      Well, some minutes with npm. With yarn, it might take a few seconds.
    - tracker1 10y ago
      I usually count on a week to boilerplate a new application. I find that spending that time to do things in a more hand-crafted way is made up for my having a consistent implementation where the structure and code make sense. Glad to see more projects moving away from `./test, ./scripts, ./views, ./styles` structure.
      - 10y ago
Lazare 10y ago
TL;DR: Author already knows Angular 1.x, doesn't have the time to learn anything new. "The stack you already know" is generally a good choice, yes. But the title is misleading and somewhat clickbait; he's not "throwing out" React; he's keeping Angular. He doesn't list any technical advantages Angular 1.x has, and in fact he labels it "obsolete" and says using it in the long term is "suicidal". A better headline is "sometimes you gotta use the crap stack you have instead of learning a new one"; nothing he says has anything to do with specific frameworks.
- jacquesm 10y ago
  Yes, but that better headline does not have two buzzwords in it.
  - sundvor 10y ago
    That headline would probably fare a lot better here, though.
- frostirosti 10y ago
  Sounds like the typical pretentious, the world is changing and I don't like it. Take the time to learn new technologies and adapt to changing landscapes. Mastering the abstract ideas makes you more flexible.
  - frostirosti 10y ago
    I mean, I do also buy the, 'change is hard, and if Cost(Change) >= Cost(Not change) + delta(x months) then it's not worth it`
  - discreteevent 10y ago
    I think the point of the article was that his goal is to develop his product before he runs out of money. Maybe if his business is a success he can then pursue your suggested goal of improving his abstract thinking and gaining flexibility.
  - deleted 10y ago
headcanon 10y ago
Sure, if you know you're faster with Angular 1.x than go for it. With your circumstances, building the product with speed should be number one priority. Personally I'd be infinitely faster with React, but thats because I have a lot more experience with it than Angular. Best of luck!
par 10y ago
Honestly I didn't find React too hard or arduous to implement anything in.
frandroid 10y ago
Has this author not heard of create-react-app? It gets the stack things out of the way.
- amadeusw 10y ago
  The stack is not stable and surprises keep popping up in development, after bootstrapping a new app.
  - hackerboos 10y ago
    The only project I've found to be more stable than create-react-app is Ember. Please elaborate.
jorblumesea 10y ago
React is a view library, Angular is a complete application framework. Two different use cases. React was never meant to supplant the Ember/Angular world. Sure you can bolt on react router etc but it's Apples and Oranges. Even if he was okay with learning a new framework under that deadline, was it even the right choice in the first place?
- tracker1 10y ago
  react, redux, react-redux, redux-thunk, react-router, fetch (or axios), material-ui, react-icons are usually what I start with, for the core of the client. Has everything I might need that angular offers, without complicated DI and weird custom DSL templates. Now this also includes webpack, babel, and some related bits. But that can be skilled by going with create-react-app
sjclemmy 10y ago
Sounds like a sensible choice. In the shadow of a deadline you haven't got time to mess about with unfamiliar stuff. I've made similar decisions. After all, if the product succeeds, you can rewrite it. If not it doesn't matter. Either way you can throw it away.
sfilargi 10y ago
> I recently quit my job to start a company. React + Redux, Go, Scala, Cassandra, micro-services, etc.. are all products made to solve Google and FB sized companies. If you are an one man band, starting your own little startup or project, stick to Python or Rails or PHP or Node, jQuery and Mongo. Your focus should be on getting something out there as soon as possible, not writing perfect software.
- tracker1 10y ago
  I wouldn't consider React + Redux particularly more difficult than an more typical MVC framework + webpage + jquery + one-off scripts. You can reach scaling (number of developers needed) issues very easily that way though.
  - sfilargi 10y ago
    In my experience React + Redux translates to 10x boilerplate. Plus if you decide to go with React, probably means you are going for SPA, which again means a lot of work you get for free in your typical html + jquery app. I agree with you on the scaling argument, but the OP is a single developer starting a new project from what I gathered, so IMHO the last thing he should worry about is scaling.
    - tracker1 10y ago
      What work you get for free? You can reuse wrapper components... can even tether the route and the wrapper together, so it's easier to manage your route/component mapping... <Router ...> <DefaultPageLayout path="/" component={DefaultPage} /> ... So the templating benefits to html/jquery are a bit of a mixed bag, and if you're doing React + Node, you can start off with your fallback route being the app, and later add server-side rendering if in a time crunch. I will say the initial setup can be higher, if you don't like the structure of create-react-app, but most people new to react coming from a PHP and Angular background probably should stick closer to as it comes in the box. Wiring up redux is the biggest paradigm shift though... unidirectional workflows mean much better predictability in terms of state with far fewer bugs. Most of the times I see weird state issues in websites/apps lately they're angular 1 though.
oheard 10y ago
Sigh. You have limited time so get on with building your product... You're procrastinating by writing an article about your insecurities with regards to using old tech in search for validation. Just do it, who gives a fuck? Good luck.
- deedubaya 10y ago
  > Just do it, who gives a fuck? It all boils down to this.
mr_tristan 10y ago
People seem to be missing that he was complaining more about the tooling around React then issues with actually coding in React. Or at least that's what I read when I read this: > However the tooling is maddening. ... After I was setup (I chose the “stable” technologies) it wasn’t good enough. As soon as I started trying to bring in libraries to do what I needed, I found my chain wasn’t up to the task. Of course I couldn’t just follow the instructions on the CLI when there were errors… because there was a few levels of indirection in the tools. I’m losing time battling my stack. It should be helping me. So this isn't "I hate React" it's more "I hate webpack/browserfy/babel/..." or whatever the hell he was trying to run with. And there's some truth to this, because the installation page of React is basically "try to get it going with your toolchain". And then a bunch of examples of working with different toolchains. Basically, he probably felt the `create-react-app` approach wasn't stable, and did a bunch of google searches to figure things out, and jumped down a rabbit hole from a variety of blogs, etc that contradicted each other, etc. I've experienced this frequently with anything non-trivial in jS-land. It's interesting, but in general, I suspect the React documentation would be better served with presenting fewer options in the early stages. "Installation" really should be "Getting Started" and that should only reference one thing, like `create-react-app`, and working with other toolchains should probably be more clearly separated out into other topics, like "Creating a production toolchain with webpack and babel".
- tracker1 10y ago
  Agreed, the documentation should have a getting started, and related tutorials working with create-react-app with more "api and tools" documentation for working in diy toolchain setups. Being able to expand on the toolchain is coming though... which I'm happy for... I want all the coming soon stuff babel can give me now, as well as my environment/test setup is different.. I want my test right next to the script that's under test for unit testing.
kapauldo 10y ago
Anyone know what he's building ?
jondubois 10y ago
For a small team of developers, I would agree that React doesn't actually add any value but it makes sense for a bigger team and a more complex product. One thing that I just can't stand about Angular 1 though, is dependency injection (which, ironically was one of their most touted 'features') - When working in a large team, I find that it's a hassle to figure out where a particular service was declared because they were magically injected into directives/controllers without any indication of where they came from; to get this workflow right requires a lot of discipline when it comes to folder structure and file naming conventions. I prefer to use the ES6 import statement as promoted by React or the tag-based module import promoted by Polymer.
hyperbole 10y ago
At the end of the day tech is just a collection of tools & for the most part those who use them are digital carpenters, so if you need to build temp scaffolding and a screw driver works better than a hammer, sure use the right tool for the job. Unclear why this is newsworthy but let me wish you the best of luck in your endeavors. If you are operating on borrowed time, let me recommend editing your /etc/hosts and blacklisting hacker news, etc. One caution since you seem to have fallen into the trap of not experimenting nor venturing out of your comfort zone -- it's a surefire way to learn nothing from this experience including what tools make you more productive... Good luck
uhryks 10y ago
Tl;dr author suffers a bit of JavaScript fatigue
jaypaulynice 10y ago
I've used Backbone/Marionette, Angular, and React at this point. I think Backbone/Marionette is the best framework so far maybe because it was the first one I did a big project on. Backboe/Marionette has very clear separation of concerns...the only true MVC framework among the 3. React is great for reusable components, but the tooling around it is so backward...I feel like I'm writing a java application and I need to piece things together. Btw I'm working on a django/react application and I have yet to figure out how to not duplicate the react routes in django. It defeats the purpose of a single page app because I don't want to reload all the same resources because a small piece of the app changes...how do you fix this?
- ptmcc 10y ago
  I agree and think Backbone/Marionette is under appreciated.
- tracker1 10y ago
  Make your 404 handler return your baseline react without preloaded state. If you use node server-side it becomes easier to do universal rendering and state injection.
  - jaypaulynice 10y ago
    Thanks! I don't want to hit the web app at all...I want to load all my static files once and then it's all client side...getting data from the rest service when it needs it...
    - tracker1 10y ago
      You can do that... if you want to handle all the routes, just make your 404 handler on the server return your base html then.
jmcgough 10y ago
The entire article body could have been deleted and replaced with "I'm taking on technical debt for a higher initial velocity"
partycoder 10y ago
The costs of taking decisions like these (e.g: using old or proprietary technologies) are: - Career growth: your team will be accruing experience in a technology the market does not need. That is not in their best interest, and they will not feel happy about it. - Hiring: It becomes difficult to hire people when you decide to move away from what everyone else is doing. - Sunk cost: As more code using old libraries is added, migration becomes more expensive.
- scarface74 10y ago
  Honest question. Could the same be said about using a technology that is not old or proprietary but not the most popular? I'm thinking in particular about Ember. I'm leaning toward Ember for our web apps because in some of our apps, any full framework is overkill and we are going with a combination of Jquery + Handlebars, but other times, we may want to use a full framework and Ember uses Handlebars for templating. I'm not seeing any jobs for Ember.
  - partycoder 10y ago
    Some technologies are not used by the vast majority of people (e.g: Erlang, Oz, Haskell, Prolog) but working with them will always offer you a valuable lesson if they teach a different paradigm. e.g: the actor model, dataflow concurrency, logic programming and so many more stuff. Those are extreme examples of different paradigms. So, the question now is: are you cultivating skills related to an obsolete paradigm, or a skill that you cannot trade in the market? If so, that's not good.
tracker1 10y ago
TL;DR; I don't have time to learn something new, sticking with what I know. This wasn't a choice for any competitive reasoning... purely panic driven. As for fast react scaffolding, it doesn't get much easier than create-react-app, or whatever the angular2+ equivalent is.
iLemming 10y ago
Good that most of us don't have that attitude - otherwise would be still patching and perforating punch cards. Angular 1.x made sense in 2009. If your job is to cut down trees and you still insist on using a hand-axe instead of learning how to operate a chainsaw, well... What can I say? "Don't stay too long in 18th century", I guess.

51 points by swalsh 10y ago

Yea, here is also one good article where you can read about both https://thinkmobiles.com/blog/angular-vs-react/ https://thinkmobiles.com/blog/angular-vs-react/

sreyaNotfilc 10y ago

The big issue with the author is having the time to build something. I wouldn't necessarily have chosen one framework/language over the other. The reason why is the author's current level of proficiency for building something that he wants. For example, if he was an ace at Assembly (instead of familiar with Angular) he could've easily wrote an article titled "Why I'm throwing out Angular 1.x and going back to Assembly". Its all relative. Some people can afford having the "most beautiful code", but that also goes with a budget and a group of people who can make it work (e.g. Steve Jobs ordering beautiful code/engineering for the Macintosh). I would say the most logical route would be to "Build the Damn Thing". Facebook used that notion, got the product out, got ahead, and now can afford sound code. Heck, Zuckerberg doesn't even code on Facebook's source anymore. No one (besides us engineers) knows or cares what Facebook is running on. Same with many other productions (not only software) out there (when was the last time we cared exactly how an Oreo cookie was made?). So to answer Steve's question "What am I supposed to do?", I would say "Just Do It! Make the product.". Do the work and live the dream (Same with all of us dreamers).

sdflkd 10y ago
> No one (besides us engineers) knows or cares what Facebook is running on. Same with many other productions (not only software) out there (when was the last time we cared exactly how an Oreo cookie was made?). Except for the people that complain about performance?
- tracker1 10y ago
  I tend to complain more about interactive state issues, Redux (or other flux-like options) helps a lot there. Performance is usually a little further down, unless it's many seconds for response. Lately every time I see weird state management issues it's almost always an angular app. And depending on what you're doing, that can be outright exceedingly painful in Angular 1.

raspasov 10y ago

It comes down to what you are most experienced and familiar with. Choosing based on that is fine, but you have to realize that might be a very bad decision mid or long term. The author seems to be aware of that so all is good. It took a few somewhat successful projects gone wrong for me to learn to prefer objectively simpler techogies technologies even if it takes extra few weeks to start. But if your hard budget deadline is literally within weeks it makes sense to prioritize fast, familiar and easy.

notliketherest 10y ago

This guy makes his situation sound pretty fucking dire and then blames react for slowing him down? It takes awhile to learn any new technology. So he goes with what he knows. How is this React's problem? I worked with React for a year and know well enough to get a brand new app up in less than a day. So it'd make sense for me to choose React. I don't understand why this guy is blaming React.

kerryritter 10y ago
I am also a React fan but phrases like "I worked with React for a year and know well enough to get a brand new app up in less than a day" make me kind of sad. The cost just to get up and running with a JS framework these days is kind of painful. CLIs are doing a decent job resolving this, though.
- headcanon 10y ago
  With create-react-app, it takes less than a few seconds, if you're fine with their defaults. If you need to mess with the webpack config it will take a bit longer but once you do it the first time its not a big deal. Putting everything together from scratch would take awhile, but that's the tradeoff of having a really flexible modular system.
  - franzpeterfolz 10y ago
    Well, some minutes with npm. With yarn, it might take a few seconds.
  - tracker1 10y ago
    I usually count on a week to boilerplate a new application. I find that spending that time to do things in a more hand-crafted way is made up for my having a consistent implementation where the structure and code make sense. Glad to see more projects moving away from `./test, ./scripts, ./views, ./styles` structure.
    - 10y ago

Lazare 10y ago

TL;DR: Author already knows Angular 1.x, doesn't have the time to learn anything new. "The stack you already know" is generally a good choice, yes. But the title is misleading and somewhat clickbait; he's not "throwing out" React; he's keeping Angular. He doesn't list any technical advantages Angular 1.x has, and in fact he labels it "obsolete" and says using it in the long term is "suicidal". A better headline is "sometimes you gotta use the crap stack you have instead of learning a new one"; nothing he says has anything to do with specific frameworks.

jacquesm 10y ago
Yes, but that better headline does not have two buzzwords in it.
- sundvor 10y ago
  That headline would probably fare a lot better here, though.
frostirosti 10y ago
Sounds like the typical pretentious, the world is changing and I don't like it. Take the time to learn new technologies and adapt to changing landscapes. Mastering the abstract ideas makes you more flexible.
- frostirosti 10y ago
  I mean, I do also buy the, 'change is hard, and if Cost(Change) >= Cost(Not change) + delta(x months) then it's not worth it`
- discreteevent 10y ago
  I think the point of the article was that his goal is to develop his product before he runs out of money. Maybe if his business is a success he can then pursue your suggested goal of improving his abstract thinking and gaining flexibility.
- deleted 10y ago

headcanon 10y ago

Sure, if you know you're faster with Angular 1.x than go for it. With your circumstances, building the product with speed should be number one priority. Personally I'd be infinitely faster with React, but thats because I have a lot more experience with it than Angular. Best of luck!

par 10y ago

Honestly I didn't find React too hard or arduous to implement anything in.

frandroid 10y ago

Has this author not heard of create-react-app? It gets the stack things out of the way.

amadeusw 10y ago
The stack is not stable and surprises keep popping up in development, after bootstrapping a new app.
- hackerboos 10y ago
  The only project I've found to be more stable than create-react-app is Ember. Please elaborate.

jorblumesea 10y ago

React is a view library, Angular is a complete application framework. Two different use cases. React was never meant to supplant the Ember/Angular world. Sure you can bolt on react router etc but it's Apples and Oranges. Even if he was okay with learning a new framework under that deadline, was it even the right choice in the first place?

tracker1 10y ago
react, redux, react-redux, redux-thunk, react-router, fetch (or axios), material-ui, react-icons are usually what I start with, for the core of the client. Has everything I might need that angular offers, without complicated DI and weird custom DSL templates. Now this also includes webpack, babel, and some related bits. But that can be skilled by going with create-react-app

sjclemmy 10y ago

Sounds like a sensible choice. In the shadow of a deadline you haven't got time to mess about with unfamiliar stuff. I've made similar decisions. After all, if the product succeeds, you can rewrite it. If not it doesn't matter. Either way you can throw it away.

sfilargi 10y ago

> I recently quit my job to start a company. React + Redux, Go, Scala, Cassandra, micro-services, etc.. are all products made to solve Google and FB sized companies. If you are an one man band, starting your own little startup or project, stick to Python or Rails or PHP or Node, jQuery and Mongo. Your focus should be on getting something out there as soon as possible, not writing perfect software.

tracker1 10y ago
I wouldn't consider React + Redux particularly more difficult than an more typical MVC framework + webpage + jquery + one-off scripts. You can reach scaling (number of developers needed) issues very easily that way though.
- sfilargi 10y ago
  In my experience React + Redux translates to 10x boilerplate. Plus if you decide to go with React, probably means you are going for SPA, which again means a lot of work you get for free in your typical html + jquery app. I agree with you on the scaling argument, but the OP is a single developer starting a new project from what I gathered, so IMHO the last thing he should worry about is scaling.
  - tracker1 10y ago
    What work you get for free? You can reuse wrapper components... can even tether the route and the wrapper together, so it's easier to manage your route/component mapping... <Router ...> <DefaultPageLayout path="/" component={DefaultPage} /> ... So the templating benefits to html/jquery are a bit of a mixed bag, and if you're doing React + Node, you can start off with your fallback route being the app, and later add server-side rendering if in a time crunch. I will say the initial setup can be higher, if you don't like the structure of create-react-app, but most people new to react coming from a PHP and Angular background probably should stick closer to as it comes in the box. Wiring up redux is the biggest paradigm shift though... unidirectional workflows mean much better predictability in terms of state with far fewer bugs. Most of the times I see weird state issues in websites/apps lately they're angular 1 though.

oheard 10y ago

Sigh. You have limited time so get on with building your product... You're procrastinating by writing an article about your insecurities with regards to using old tech in search for validation. Just do it, who gives a fuck? Good luck.

deedubaya 10y ago
> Just do it, who gives a fuck? It all boils down to this.

mr_tristan 10y ago

People seem to be missing that he was complaining more about the tooling around React then issues with actually coding in React. Or at least that's what I read when I read this: > However the tooling is maddening. ... After I was setup (I chose the “stable” technologies) it wasn’t good enough. As soon as I started trying to bring in libraries to do what I needed, I found my chain wasn’t up to the task. Of course I couldn’t just follow the instructions on the CLI when there were errors… because there was a few levels of indirection in the tools. I’m losing time battling my stack. It should be helping me. So this isn't "I hate React" it's more "I hate webpack/browserfy/babel/..." or whatever the hell he was trying to run with. And there's some truth to this, because the installation page of React is basically "try to get it going with your toolchain". And then a bunch of examples of working with different toolchains. Basically, he probably felt the `create-react-app` approach wasn't stable, and did a bunch of google searches to figure things out, and jumped down a rabbit hole from a variety of blogs, etc that contradicted each other, etc. I've experienced this frequently with anything non-trivial in jS-land. It's interesting, but in general, I suspect the React documentation would be better served with presenting fewer options in the early stages. "Installation" really should be "Getting Started" and that should only reference one thing, like `create-react-app`, and working with other toolchains should probably be more clearly separated out into other topics, like "Creating a production toolchain with webpack and babel".

tracker1 10y ago
Agreed, the documentation should have a getting started, and related tutorials working with create-react-app with more "api and tools" documentation for working in diy toolchain setups. Being able to expand on the toolchain is coming though... which I'm happy for... I want all the coming soon stuff babel can give me now, as well as my environment/test setup is different.. I want my test right next to the script that's under test for unit testing.

kapauldo 10y ago

Anyone know what he's building ?

jondubois 10y ago

For a small team of developers, I would agree that React doesn't actually add any value but it makes sense for a bigger team and a more complex product. One thing that I just can't stand about Angular 1 though, is dependency injection (which, ironically was one of their most touted 'features') - When working in a large team, I find that it's a hassle to figure out where a particular service was declared because they were magically injected into directives/controllers without any indication of where they came from; to get this workflow right requires a lot of discipline when it comes to folder structure and file naming conventions. I prefer to use the ES6 import statement as promoted by React or the tag-based module import promoted by Polymer.

hyperbole 10y ago

At the end of the day tech is just a collection of tools & for the most part those who use them are digital carpenters, so if you need to build temp scaffolding and a screw driver works better than a hammer, sure use the right tool for the job. Unclear why this is newsworthy but let me wish you the best of luck in your endeavors. If you are operating on borrowed time, let me recommend editing your /etc/hosts and blacklisting hacker news, etc. One caution since you seem to have fallen into the trap of not experimenting nor venturing out of your comfort zone -- it's a surefire way to learn nothing from this experience including what tools make you more productive... Good luck

uhryks 10y ago

Tl;dr author suffers a bit of JavaScript fatigue

jaypaulynice 10y ago

I've used Backbone/Marionette, Angular, and React at this point. I think Backbone/Marionette is the best framework so far maybe because it was the first one I did a big project on. Backboe/Marionette has very clear separation of concerns...the only true MVC framework among the 3. React is great for reusable components, but the tooling around it is so backward...I feel like I'm writing a java application and I need to piece things together. Btw I'm working on a django/react application and I have yet to figure out how to not duplicate the react routes in django. It defeats the purpose of a single page app because I don't want to reload all the same resources because a small piece of the app changes...how do you fix this?

ptmcc 10y ago
I agree and think Backbone/Marionette is under appreciated.
tracker1 10y ago
Make your 404 handler return your baseline react without preloaded state. If you use node server-side it becomes easier to do universal rendering and state injection.
- jaypaulynice 10y ago
  Thanks! I don't want to hit the web app at all...I want to load all my static files once and then it's all client side...getting data from the rest service when it needs it...
  - tracker1 10y ago
    You can do that... if you want to handle all the routes, just make your 404 handler on the server return your base html then.

jmcgough 10y ago

The entire article body could have been deleted and replaced with "I'm taking on technical debt for a higher initial velocity"

partycoder 10y ago

The costs of taking decisions like these (e.g: using old or proprietary technologies) are: - Career growth: your team will be accruing experience in a technology the market does not need. That is not in their best interest, and they will not feel happy about it. - Hiring: It becomes difficult to hire people when you decide to move away from what everyone else is doing. - Sunk cost: As more code using old libraries is added, migration becomes more expensive.

scarface74 10y ago
Honest question. Could the same be said about using a technology that is not old or proprietary but not the most popular? I'm thinking in particular about Ember. I'm leaning toward Ember for our web apps because in some of our apps, any full framework is overkill and we are going with a combination of Jquery + Handlebars, but other times, we may want to use a full framework and Ember uses Handlebars for templating. I'm not seeing any jobs for Ember.
- partycoder 10y ago
  Some technologies are not used by the vast majority of people (e.g: Erlang, Oz, Haskell, Prolog) but working with them will always offer you a valuable lesson if they teach a different paradigm. e.g: the actor model, dataflow concurrency, logic programming and so many more stuff. Those are extreme examples of different paradigms. So, the question now is: are you cultivating skills related to an obsolete paradigm, or a skill that you cannot trade in the market? If so, that's not good.

tracker1 10y ago

TL;DR; I don't have time to learn something new, sticking with what I know. This wasn't a choice for any competitive reasoning... purely panic driven. As for fast react scaffolding, it doesn't get much easier than create-react-app, or whatever the angular2+ equivalent is.

iLemming 10y ago

Good that most of us don't have that attitude - otherwise would be still patching and perforating punch cards. Angular 1.x made sense in 2009. If your job is to cut down trees and you still insist on using a hand-axe instead of learning how to operate a chainsaw, well... What can I say? "Don't stay too long in 18th century", I guess.