Earlier quoted context omitted.
CGI + Perl?
CGI::Application + Perl paid my bills for many years back in its day.
Likewise
I Miss Rails
321–330 of 522 posts
Re: I Miss Rails
#322Earlier quoted context omitted.
What purpose does it serve to take such an uncharitable view on other people? This community is full of experienced professionals who use Javascript even in the face of alternative options, and we belabor this topic every day. So what excuse do you have for assuming and hypothesizing that everyone must be an unenlightened boot camp amateur when you could've turned to anyone and simply asked? For example, to me, moder…
All that's nice at the language level in favor of JS, but it doesn't speak to the framework level of what all Rails offers compared to everything additional you need to add to React to be comparable. Same deal for some of the frameworks in PHP like Laravel or Drupal.
Comparing React vs Rails is like comparing an iOS app to Rails. I don't really see the point since they are fundamentally different, and whether your application should run on the client or not is a bedrock decision long before you get to "React vs Rails". Rails isn't even an option in one of the branches of that decision.
I assume you meant to instead draw a distinction between a large framework like Rails and a tiny one like Sinatra. And I'd say that ranges from a matter of taste to the composition of your team more than anything else. Obviously there are upsides and downsides to any point you can mark on the continuum.
Re: I Miss Rails
#323Earlier quoted context omitted.
I feel like as a collective set of industries across development and security we have been telling people for years not to reinvent the wheel because it's easier to stand on the shoulders of giants. Despite this, there seems to be an increasing push (from, for example, Go programmers) to go back to DIY. Is this not tearing away all the work we've done to stop people building their own auth, their own crypto, their ow…
I should backtrack a tiny bit before I'm downvoted to oblivion. I'm not opposed to libraries to handle a lot of stuff (like auth, crypto, and file I/O). I think it's typically irresponsible to reinvent these things for any reason other than "it's a fun personal project". What I dislike about a lot of the frameworks is how locked-in I feel. There's (often) only one way to do things, and I don't always feel it's the be…
Sure, the framework's way might not always be the best way of doing things but I prefer to just accept it and move on. It saves spending time debating, deciding, experimenting with different ways of structuring code, when it probably doesn't really make that big of a difference in the end anyway. Most web applications are really not that different from each other.
On top of that it prevents really bad coders from rolling their own in a really bad way. Remember when everybody was coding their own MVC framework in PHP?
As for C# not parsing JSON correctly, that seems more like a problem with a language or library not anything to do with frameworks?
Re: I Miss Rails
#324Yep, 100%. In the process of converting a node/typescript API to rails. I'll never make this mistake again.
You’re going from TypeScript to Ruby? Having tasted the joys of static type checks combined with a unified front/back data model, IMHO, that’s unthinkable.
Static typing is nice, but the tradeoff of all the wonderful ruby library support far outweighs the node ecosystem. I found myself fighting with so many poorly-executed, half-abandoned, relatively popular (mongoose). Stuff in ruby land Just Works™. Do I want to be writing type defs for some dying library, or building features? Unfortunately, this is consistently the node ecosystem trade off.
Re: I Miss Rails
#325> The world of tech moves fast, and there’s always new frameworks and paradigms popping up that make developers’ lives easier and allow us to build more and more powerful applications.
I wish people didn't start their posts with such proclamations. Why can't one just go ahead and criticize something without first giving it a compulsory doze of praise.
Re: I Miss Rails
#326Earlier quoted context omitted.
With TypeScript you can define a single set of interfaces shared by both your client side and server code. If you change an interface to return a different value or rename a member, you immediately know where it’s used and can update it in tandem. Static type checking let’s you know everywhere that something is used without a battery of tests running through your app. This takes 99% of the fear out of refactoring and…
You get all of that for free with Java, plus you don't have to use javascript
Or Go. Or Crystal, if similarity to Ruby is preferred. You get the advantages of static typing plus the performance of a compiled language.
Re: I Miss Rails
#327I have been dabbling with Elixir + Elm. This can be the next big thing, once live view gets wider adoption.
Re: I Miss Rails
#328Earlier quoted context omitted.
Though now you're in Event Machine world and can't use the rest of the ecosystem. One of the frequently overlooked properties of Javascript/Node is that it's async-everything. I'd be curious to hear more about this benchmark.
This might come as a surprise, but async everything is not a feature for a lot of people. It’s a bug.
Yes, of course. Everything is a trade-off. Why the condescension?
But there are almost zero async-everything options in the space. And being confined to a second-class async subworld inside a synchronous ecosystem is a classic error-prone challenge whether you're using Twisted, Event Machine, Tokio, or Netty.
It's a pretty big downside of using Event Machine which even created its own networking primitives instead of using those in the Ruby stdlib.
Re: I Miss Rails
#329I don't miss rails. It's there and it's awesome. Can't wait till crystal is far enough so there's better type checking, or for ruby to implement that.
And I can't wait for activerecord to be replaced by something like objectmapper.. It makes a lot more sense.
Re: I Miss Rails
#330Earlier quoted context omitted.
All that's nice at the language level in favor of JS, but it doesn't speak to the framework level of what all Rails offers compared to everything additional you need to add to React to be comparable. Same deal for some of the frameworks in PHP like Laravel or Drupal.
Comparing React vs Rails is like comparing an iOS app to Rails. I don't really see the point since they are fundamentally different, and whether your application should run on the client or not is a bedrock decision long before you get to "React vs Rails". Rails isn't even an option in one of the branches of that decision. I assume you meant to instead draw a distinction between a large framework like Rails and a tin…
I meant that if the Ruby community had an inherent preference for Sinatra-like frameworks such that Rails had the same status as Meteor or Sails does these days, then you would get articles by developers saying how they miss Django when having to reimplement a bunch of stuff in Sinatra that you automatically get with Django.
But you're right that I made an invalid comparison to React. It's more the starting with Node and having to add a bunch of functionality that you would get out of the box in Rails, because a front-end framework like React is the preference, and lots of developers would rather write isomorphic apps/sites.