Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After reading “Rails is yesterday’s software”, I need to reply

codethinked.com

Post reply on HN
Print view View original

51–60 of 219 posts

Re: After reading “Rails is yesterday’s software”, I need to reply

#51

Post by jsmith0295 »

estrabd wrote: post #32
n0us wrote: post #10

Some software does become "yesterday's software." I'm looking at you Cold Fusion, Flash, COBOL, the Abacus. I don't think Rails belongs in this group. I recognize that it's a good framework even if I don't personally like.

Interesting comment; I believe if you are going to implicate Cold Fusion, you also need to rope in PHP. My first exposure to web programming was HTMLScript at my university in the mid 90s (now called MivaScript and is the language used to build the MivaMerchant product). Soon after, I switched to PHP 3, but I found that I preferred Miva. I have not touched Miva in years after spending some time as a freelancer in the…

This isn't really the case. There are modern web frameworks for PHP -- https://laravel.com/ is the best example

Re: After reading “Rails is yesterday’s software”, I need to reply

#52

Post by Tenhundfeld »

askyourmother wrote: post #23
hashkb wrote: post #15

Author is being nice, but I'm happy to point out that author of replied-to post is revealing they are a frustrated novice. All the focus on "Rails made programming cool" tells me "I do things for dumb reasons." Clear case of chasing the dragon.

Aren't most if not all Rails programmers just chasing shiny magic features? Rails programmers tend to be like a McDonald's happy meal - uninspired, fills a hole, make do.

Your comment comes across as narrow-minded and frankly, a bit arrogant. It is just so dismissive. Rails's original popularity came from developers fleeing the excessive ceremony and boilerplate code of enterprise Java – and .NET to some extent.

Sure, there are some inexperienced (or simply bad) developers in the Rails community, just as there are in every community. But most of the Rails developers I've met also have experience in at least one other major web stack. They're not chasing "shiny magic features". They're chasing productivity.

For me personally, Rails offers greater productivity than any other web framework I've used. The truth is Ruby has little to do with that, as much as I happen to like the language. I could go on for quite a while about why I feel Rails offers the best productivity, but it boils down to two main points: the entire Rails community is focused on building web applications, and the Rails core team is mostly comprised of people actually building web applications. Features get added because they're needed. Common frictions get ironed out.

Rails isn't about "magic". Rails is about getting shit done, quickly and mostly-cleanly.

Re: After reading “Rails is yesterday’s software”, I need to reply

#53

Post by cdnsteve »

"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 bugs and consume all your resources to fix. Remember left-pad?

This is true in any language and ecosystem and has nothing to do with rails/gems/ruby. The same is with Python, JS, PHP.

Senior/Lead devs need to carefully curate what a projects foundation is. A strong, well designed foundation means you have something solid to build on. If you don't understand what's in your deps, haven't read their code, see how often it's updated and how many people actively use it, and can say you are using 80% or more of the code in it then don't use it.

Writing your own code is often the best route since it fixes your exact use case, no matter the language, libraries or frameworks being used.

Re: After reading “Rails is yesterday’s software”, I need to reply

#54

Post by carsongross »

lmm wrote: post #49
carsongross wrote: post #13

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…

Rails is still page-oriented, no? I've found Wicket is head and shoulders above anything else for actually producing HTML, and it can already do lightweight partial ajax updates to the UI if that's the style you're suggesting.

Rails lets you render partials directly.

I've never used wicket, but it looks pretty good at this sort of thing.

Re: After reading “Rails is yesterday’s software”, I need to reply

#55

Post by pjmlp »

blub wrote: post #6

This is the old "use the right tool for the job" cop-out. The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Or do we need an entire new class of tools which have traditionally been used to build large scale systems in the past? It's a multi-faceted question of type systems, toolin…

> can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript?

For me, after the experience working on a startup that used TCL using an approach similar to AOLserver back in the first .com wave, web apps are always built with JVM, .NET or any other JIT/AOT enabled language toolchain with JavaScript kept for its indisputable place on the browser.

Re: After reading “Rails is yesterday’s software”, I need to reply

#56

Post by MustardTiger »

forgotpwtomain wrote: post #42
blub wrote: post #30

Earlier quoted context omitted.

Why not? I would be curious to see how people tackle large, complex web software in an efficient way - that is with tools support, not by fighting against them and working around inadequacies. Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing. And here's some examples of complex software for comparison: image editor, digital audio workstation, CAD, video confere…

> Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing Unit tests are checking a lot more than argument type.. I have no idea what environment you worked in, but the comment comes across as rather clueless.

A huge portion of unit tests are doing exactly that. Many people simply don't realize how many problems are actually type problems. Like null/nil/whatever as the most trivial example. It is more likely that your comment is made out of ignorance than the one you replied to.

Re: After reading “Rails is yesterday’s software”, I need to reply

#57

Post by askyourmother »

Tenhundfeld wrote: post #52
askyourmother wrote: post #23

Earlier quoted context omitted.

Aren't most if not all Rails programmers just chasing shiny magic features? Rails programmers tend to be like a McDonald's happy meal - uninspired, fills a hole, make do.

Your comment comes across as narrow-minded and frankly, a bit arrogant. It is just so dismissive. Rails's original popularity came from developers fleeing the excessive ceremony and boilerplate code of enterprise Java – and .NET to some extent. Sure, there are some inexperienced (or simply bad) developers in the Rails community, just as there are in every community. But most of the Rails developers I've met also have…

Uhhm, it certainly is about magic, it's creator goes on about that quite a bit. So the happy meal developers don't really have to know how to code. Just install these gems, copy these incantations from the pragprog book, you too can have your site in five minutes.

You don't need to understand the shiny magic, I mean, it detracts from being saying "I'm a Rails developer", but maybe it would help if they did.

Re: After reading “Rails is yesterday’s software”, I need to reply

#58

Post by incepted »

cdnsteve wrote: post #53

"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.

Re: After reading “Rails is yesterday’s software”, I need to reply

#59

Post by IshKebab »

quetzthecoatl wrote: post #50
mbell wrote: post #16

Earlier quoted context omitted.

> The original post went deeper than that. If there was depth, I missed it. The only two points I got from it were 'I prefer static typing over duck typing' and 'avoid dependency hell'. The original post didn't add anything new to either argument and both have existed and been rehashed over and over again for decades.

also, the image of a pig's face as electric socket while hilarious, shows how much the original author mis understood duck typing. It's not just look like duck, but also quack like a duck. Since when does a pig's nose behave like an electric socket? The idea behind duck typing is about concentrating on behavior instead of identities. He completed missed it.

It was just a funny picture. And besides, duck typing doesn't rely on things behaving the same. It relies on them appearing the same (in terms of method names). A pigs nose appears like an electrical socket in that it has holes in the same places. So actually it is a pretty accurate picture.

That said, I don't think duck typing is Python's biggest problem. Go sort-of has duck typing, in that you can make a type implement an interface just by giving it methods of the right names. It's a bit safer because you have to specify the 'ducks' though. It's kind of static duck typing.

Rust gets it totally right. But anyway the dynamic typing is a far worse issue than duck typing.

Re: After reading “Rails is yesterday’s software”, I need to reply

#60

Post by toolz »

cdnsteve wrote: post #53

"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…

I work on some really big projects in the wild for various clients in ruby on rails and they have so many gems that often I find unused gems they are afraid to remove them in case it actually is being used, but you know what? They were moving forward with features - their user base was happy and their product worked for the most part.

You know what kinds of projects I see fail? The ones who try to architect everything using a core set of libraries and build everything themselves. I've seen hugely funded projects with years of development burn for that very reason.

I know I'm just a single datapoint, but it's worth mentioning that there exists projects that absolutely will do better in the long run with just installing all the gems.

Post reply on HN