I think the author is looking for Angular + Firebase...
Don't make me think, or why I switched to Rails from JavaScript SPAs
241–250 of 490 posts
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#242Earlier quoted context omitted.
I think Ember was a lot closer to a complete framework. I do believe that that's also why it didn't gain as much popularity. The learning curve was a lot steeper than for React or Angular. You won't run into the problems with the slimmer libraries till later and at that point you understand them and "just" learn the new thing, Redux or wherever you are including now. All along the way it feels smooth, but you end up…
I built a product and we bet on Ember back when it, angular and react all looked like top choices. I’d say one of the biggest failures was that it didn’t provide clean upgrades We got stuck with 3.something and no clear path forward. Second, it wanted everything to be Emberized. I forget what exactly it was, but we struggled to wrap other tools in service containers so that they could be injected into our code. I thi…
I agree ember had issues in the past, but it's come a long way and the latest version Octane/4.0 is pretty solid.
For anyone curious linkedin.com is a massive ember.js app and they're big contributors to the project.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#243Google searches for React and node.js exceed searches for Ruby on Rails by 100% and 50%, respectively [1]. Some people have used this to argue that React/node are more popular than Rails. But I wonder if perhaps this discrepancy appears in Google Trends because it takes more google searches to accomplish the same thing in React/node versus Rails. I feel the Rails ethos of "convention over configuration" allows me to…
As someone who came from other MVC frameworks outside of Ruby, learning Rails has been a cluster-f of searching through documentation circa 2013. The whole rails “convention over configuration makes it easier” is a load of bologna, because the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts. The best way to work on rails is t…
What are some specific “magical things” that are not mentioned in the rails guides?
There’s always room for improvement and the documentation is an important part of the framework.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#244Earlier quoted context omitted.
Honestly Angular is great even for startups. With the current state of the the framework and the way the Angular CLI bundles code, it's pretty hard to break 90 on PageSpeed Insights (at least without pre-rendering). But it's also not that difficult to get in the high 80s, which is pretty good for a SPA. And it should only be getting more performant as they put more working into optimizing it. It's easy to learn, the…
> And it should only be getting more performant as they put more working into optimizing it. You say this like it's not an 8 year old framework. I wouldn't have such high hopes for it rising significantly.
Well there are basically only two things that need to happen:
- The number of round trips needed to render a page needs to go from 3 to 2.
- The amount of JavaScript in the core framework needs to be slimmed down.
The second is already on the roadmap -- they are making Zone.js optional, and supposedly the next version of RxJS is going to be significantly smaller. In order for this to actually happen, Google needs to keep funding the project for at least another full year, which seems likely given how much they depend on it. In terms of the former -- well, it seems increasingly likely that they'll work on adding those kinds of options to the CLI once they get through with the other stuff. And if not, you can alway go back to straight Webpack and just do it yourself. (I personally like the benefits of the CLI and not having to deal with Webpack, but if Webpack keeps improving then who knows, maybe I'll switch back.)
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#245Earlier quoted context omitted.
I don't follow this logic. Why do you end up with JS strewn everywhere? Sounds like poor organization practices. 1. User arrives at a page where a real-time widget may exist. widgets/mywidget.js on that page. 2. User triggers mywidget.js by pressing a button or just existing. It dynamically creates the widget elements, requests a secure websocket, then sets up input/output handlers. 3. Done. mywidget.js could be big…
I'm not talking about how my javascript source files are organized, I'm talking about how the functions are dispatched from the UI. That is done with event listeners strewn about in the DOM.
What is so complicated about
If you are referring to "the page is the widget" then you need to make a very good case why wrapping all the HTML in JS is in your interest. Facebook has an interest in doing this because they want to wrap every element in a bit of JS so they can closely track user behavior. Briefly hovering over a link, button or ad? Facebook wants to know everything about that interaction, in order to provide value to their clients (i.e. advertisers).
A normal developer is happy with that element just being a `` or ``. The entire page does not need to be a JS widget (SPA).
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#246As someone who is in the same position as author, Angular + Firebase is a very helpful alternative to moving to Rails while providing the benefits of an SPA.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#247The article makes a comparison to react, but that’s a front end library. Does rails also do front end?!
React is a client side framework (no, it's not a library even if they say it is), not an "app".
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#248Google searches for React and node.js exceed searches for Ruby on Rails by 100% and 50%, respectively [1]. Some people have used this to argue that React/node are more popular than Rails. But I wonder if perhaps this discrepancy appears in Google Trends because it takes more google searches to accomplish the same thing in React/node versus Rails. I feel the Rails ethos of "convention over configuration" allows me to…
As someone who came from other MVC frameworks outside of Ruby, learning Rails has been a cluster-f of searching through documentation circa 2013. The whole rails “convention over configuration makes it easier” is a load of bologna, because the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts. The best way to work on rails is t…
"Reading docs top to bottom" is the answer to this frustration. It's strange that people don't think this is something they should do.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#249Google searches for React and node.js exceed searches for Ruby on Rails by 100% and 50%, respectively [1]. Some people have used this to argue that React/node are more popular than Rails. But I wonder if perhaps this discrepancy appears in Google Trends because it takes more google searches to accomplish the same thing in React/node versus Rails. I feel the Rails ethos of "convention over configuration" allows me to…
I would suspect searches are overwhelmingly weighted to beginners to a particular environment.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#250Google searches for React and node.js exceed searches for Ruby on Rails by 100% and 50%, respectively [1]. Some people have used this to argue that React/node are more popular than Rails. But I wonder if perhaps this discrepancy appears in Google Trends because it takes more google searches to accomplish the same thing in React/node versus Rails. I feel the Rails ethos of "convention over configuration" allows me to…
As someone who came from other MVC frameworks outside of Ruby, learning Rails has been a cluster-f of searching through documentation circa 2013. The whole rails “convention over configuration makes it easier” is a load of bologna, because the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts. The best way to work on rails is t…
If that's not bad enough you're probably working on a legacy app with a whole bunch of mix-ins, proxies, Active Record callbacks, and other nonsense that makes it nigh on impossible to understand what any code does.