101–110 of 219 posts
Earlier quoted context omitted.
A huge upgrade on code with no tests and a bunch of magical dependencies? The problem wasn't Rails there.
There's an argument to be made that Rails, by not actually enforcing conventions like TDD, gives an amateur/impatient developer a very high calibre footgun. Unfortunately, of course, that gun doesn't usually go off until it's handed to someone else.
Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x... 4.1.x -> 4.2.x It was, and still is, a nightmare. Technically speaking Rails itself upgraded in a reasonably straight-forward way, just follow the documentation (well and a few blog posts here and there for the things missed in the official docs). But all the additional Gems, and dependencies of those Gems (and so on) made the process excruc…
There are few ways this could be addressed, e.g. separate branches for old gems, and some developers do actually do this but in the end I've noticed these legacy branches and gems just bitrot while the developer devotes their time to the new branch. So essentially to use the gem you have to make the SemVer API jump which then begins the dependency failure cascade dance you mention.
I'm close to starting another new Rails job and I'm not looking forward to the inevitable rails rescue work on legacy codebases, yet this is the reality of a modern Rails developer.
Also I think this upgrade work needs to be factored into "development time" and when you do I'm not convinced Rails is actually faster.
Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory. 'Tomorrow's' languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and…
At my current job we primarily use Wordpress. Why Wordpress? Because we have a large and non-technical content team, 260+ websites and several tens of thousands of pages of content that need to go up quickly.
We're just 4 developers - about 1 for every 8 content & marketing people we have. We spend very little of our time on frontend. Tell me that you're going to get that kind of leverage with another tool.
Wordpress is just about the last thing that you would pick as a developer or ops person to base your tech stack, but in our case it is the right choice.
Aside: Coming from Rails and having spent six months deep in Wordpress core, it's actually kind of awesome. Seemingly every problem is solvable.
Earlier quoted context omitted.
This isn't really the case. There are modern web frameworks for PHP -- https://laravel.com/ is the best example
Also PHP still powers much of the web and has taken a step forward with PHP 7 which seems to run a good bit faster than Ruby and the like.
Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x... 4.1.x -> 4.2.x It was, and still is, a nightmare. Technically speaking Rails itself upgraded in a reasonably straight-forward way, just follow the documentation (well and a few blog posts here and there for the things missed in the official docs). But all the additional Gems, and dependencies of those Gems (and so on) made the process excruc…
I've found upgrade hell can apply to C#/dotnet stuff too. I work on a project that has attempted to upgrade Entity framework versions multiple times and keeps pushing it off because we get buried in compile time errors. It's a case where Microsoft supported several different paths to architect an app and then quietly deprecated half of them - database first vs. code first, POCOs vs. ObjectContext, etc. and we happene…
"makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug". This "let someone else do the work, get it from a gem" mindset is what kills long lived projects. It has nothing to do with the tools and everything to do with experience. You don't need 1000 gems. Managing anything more than core dependancies in a project can easily create exponential bu…
> This "let someone else do the work, get it from a gem" mindset is what kills long lived projects If you replace "gem" with "library", this actually makes a lot of sense. It saves time to reuse existing (high quality) software. Plenty of ecosystems do just fine with this mindset, starting with the JVM and .net. The problem is specifically Ruby and the gems system.
Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory. 'Tomorrow's' languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and…
All our webapps these days are thin React apps (with server-side rendering) that don't have a dedicated backend. Instead, they talk to a group of generic microservices. We've been doing this style of development since around 2010.
With this methodology, a lot of Rails' ergonomic concerns (templating, the split between rendering HTML vs. data, etc.) just melt away. Front-ends become formally isolated clients of microservices, forcing you to engineer better internal APIs and get things like security correct from the start.
I've got my problems with Rails: routing is overly complicated, the asset pipeline can be tricky, and so on. But Rails is very good at producing HTML and, in particular, partial chunks of HTML. As the current thick-clients-in-javascript trend cools off (it's happening, this was at the top of /r/webdev yesterday: https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_p... ) people are going to migrate back to HTML…
I think that's wishful thinking.
The drawing you link is great though.
Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x... 4.1.x -> 4.2.x It was, and still is, a nightmare. Technically speaking Rails itself upgraded in a reasonably straight-forward way, just follow the documentation (well and a few blog posts here and there for the things missed in the official docs). But all the additional Gems, and dependencies of those Gems (and so on) made the process excruc…
The main problem I see in the ruby community, in this regard, is the willingness to make breaking changes and justify it via Semantic Versioning. While on the surface this seems ok the underlying problem, as I see it, is the old version isn't maintained, so essentially the only maintained version now has breaking API changes. There are few ways this could be addressed, e.g. separate branches for old gems, and some de…
The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march.
A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and the return output of their methods are documented.
I've got my problems with Rails: routing is overly complicated, the asset pipeline can be tricky, and so on. But Rails is very good at producing HTML and, in particular, partial chunks of HTML. As the current thick-clients-in-javascript trend cools off (it's happening, this was at the top of /r/webdev yesterday: https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_p... ) people are going to migrate back to HTML…
...thinks like WebAssembly will be ramping up, spurring a trend of thick-clients-in-other-than-JavaScript.