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

41–50 of 219 posts

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

#41

Post by carsongross »

67726e wrote: post #33
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…

What makes you think that being able to produce HTML is such an important piece, and that Raila delivers better than most other frameworks?

HTML gives you HATEOAS without thinking about it:

http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

and is the minimum level of complexity necessary for a human web interface.

Rails isn't necessarily better than other platforms at producing HTML: it does support rendering partials which is nice: http://guides.rubyonrails.org/layouts_and_rendering.html. So, rails is pretty good at it, but I can imagine other tools being perfectly competent at the problem as well.

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

#42

Post by forgotpwtomain »

blub wrote: post #30
carsongross wrote: post #22

Earlier quoted context omitted.

can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? They absolutely can be built using just Rails (or python) and HTML. I won't shill any harder about how, but it's not only possible, it's enjoyable and easy. I've done it.

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.

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

#43

Post by [deleted] »

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…

[deleted]

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

#44

Post by carsongross »

blub wrote: post #30
carsongross wrote: post #22

Earlier quoted context omitted.

can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? They absolutely can be built using just Rails (or python) and HTML. I won't shill any harder about how, but it's not only possible, it's enjoyable and easy. I've done it.

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…

Mmm. By that definition, I would not define the software I built as "complex". But I also wouldn't define Facebook, GMail or Stripe's web app as "complex" either, and I see folks using very complicated client-side technology to build those "simple" apps.

I use intercooler.js, which I built, and which I shill heavily because I'm quixotically trying to fight the Facebook/Google 80's-style-thick-clients-in-javascript zeitgeist.

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

#45

Post by mbell »

blub wrote: post #25
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.

The trick is to ignore everything until the "duck typing" picture including the picture. Then to pay attention to the last four paragraps.

There still isn't much there, and some of it is just unfounded.

For example, while the author claims there are 'crazy levels of duck typing' in Ruby / Rails he provides no such evidence of it and as noted by recent work from Aaron Patterson the vast majority of calls sites even in a very large rails app are actually monomorhpic (https://www.youtube.com/watch?v=6Dkjus07d9Y).

But more important than this cherry picked example is the complete lack of this type of technical discussion, which is why I find the post very shallow.

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

#46

Post by emodendroket »

Avshalom wrote: post #36
emodendroket wrote: post #11

Earlier quoted context omitted.

Well, why not? "My team and I are familiar with these tools and confident that we can use them to deliver the desired result" seems like a fine reason to call something the right tool for the job.

They aren't the same thing but there's basically no room between "these are the tools I know"-thinking and "if all you have is a hammer"-thinking. Freely admit this is somewhat irrelevant though as most languages are the difference between a felling-ax and a splitting-ax or two sizes of screwdriver, as opposed to hammer vs drill.

Well, I assume most people have a handful of tools they are familiar with and choose from among them (although the proliferation JavaScript-based stuff absolutely everywhere might call that assumption into question).

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

#47

Post by lmm »

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.

Unit tests check a lot more than whether the argument is Int or String, but so do good type systems. I'd say your comment comes across as more clueless.

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

#48

Post by lmm »

criddell wrote: post #29
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…

> In the future it might mean using (gulp) Java + WebAssembly You know, after being out of the Java world for about ten years now, I'm starting to get the itch to use it again. I was one of those people that used to joke about programming in XML, but that's really just a layer of indirection which is often a good solution to a problem. It's a very nice language, is fast, and has so far not been destroyed by Oracle. P…

Let me take the opportunity to plug Scala, which gives you (better than) the expressiveness of Python or Ruby but with (better than) the safety of Java. (OCaml, F# or Haskell are other options in a similar quadrant).

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

#49

Post by lmm »

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.

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

#50

Post by quetzthecoatl »

mbell wrote: post #16
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…

> 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.
Post reply on HN