41–50 of 123 posts
Omakase implies a certain level of excellence in all the individual choices. I believe Rails is In-N-Out Burger. While it offers few choices, it's reliable and the hamburger is very good. The fries and frontend framework are acceptable but no one goes to In-N-Out for the fries.
I never understood why rails has javascript helpers at all. It just does not bring any value in the long run, just complicates stuff. Rails should be js libraries agnostic and not provide any js related helpers out of the box in my opinion.
Earlier quoted context omitted.
This is one of the best things about Django - outside the admin interface it's not opinionated about your frontend setup.
Of course "not opinionated" in this case is an euphemism and really means that Django doesn't help you at all and so you have to suffer the incomplete and abandoned middleware of others to have something that resembles an asset pipeline. And that's actually odd, because both Rails and Django are frameworks born for building frontends to MySQL databases, which means these frameworks really are about HTTP 1.1 frontend…
Is it the best solution when you just want to stream data down a socket? No. That doesn't mean it's useless for many other things.
If I'm going down the SPA route I'd just build the frontend separately using ember-cli or webpack or some other "native" solution and forget any asset pipeline.
Rails should stop messing with Javascript all together. Drop JQuery, CoffeeScript, TurboLinks and what not and let the users decide what to use, make it optional. Rails shouldn't require a JS engine in order to run.
Rails tries to set most of the best practises for you so that you don't need to make bad decisions on out-of-scope things. just focus on the actual problem. If you are well aware of how things are working and it doesn't fit you, then you can start with Sinatra or rewrite the parts that are not good in Rails.
But just saying Rails should drop JS doesn't doesn't add much unless you have a better solution.
Earlier quoted context omitted.
The problem isn't jQuery, the problem is that 90% of the use cases for jQuery can now be solved with native APIs (or polyfills if compatibility with older browsers is a requirement). The main feature is basically element.querySelectorAll (or document.querySelectorAll for the global version). The XHR wrapper can easily be replaced with the fetch API. Class list manipulation is easy with element.classList. The event li…
> The XHR wrapper can easily be replaced with the fetch API. Browser support for fetch is still pretty weak, so you'll need some kind of polyfill to use it today. http://caniuse.com/#feat=fetch
An alternative would be to initiate a discussion with jQuery as obviously Rails isn't the only framework that's dealing with this issue. Let the jQuery guys do what they're great at, let Rails do what it does.
Rails should stop messing with Javascript all together. Drop JQuery, CoffeeScript, TurboLinks and what not and let the users decide what to use, make it optional. Rails shouldn't require a JS engine in order to run.
Earlier quoted context omitted.
So did you do JS development back in 2006 without jQuery?
The first few years I did PHP without much client side scripting. Then ExtJS, then a short stint with Ember and after that React.
Omakase implies a certain level of excellence in all the individual choices. I believe Rails is In-N-Out Burger. While it offers few choices, it's reliable and the hamburger is very good. The fries and frontend framework are acceptable but no one goes to In-N-Out for the fries.
Earlier quoted context omitted.
The first few years I did PHP without much client side scripting. Then ExtJS, then a short stint with Ember and after that React.
What was your experience with Ext? I had to use it for a few years, and was never a huge fan. We ran into a lot of obscure bugs in their code which resulted in a number of hackaround "Ext.Overrides," and their support forums (Mitch Simmeons in particular) is a joke.
I only used ExtJS 4 and 4.1
I liked their API documentation and the xtypes that allowed for declarative Views. React reminded me of this later.
This single comment absolutely confirms that point of view: https://github.com/rails/rails/issues/25208#issuecomment-222...