Live data from Hacker News

Don't make me think, or why I switched to Rails from JavaScript SPAs

reviewbunny.app

121–130 of 490 posts

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#121

I think the author went too deep into details here, as this crowd is full of people who are going to be able to rip pieces of this article to shreds. But doing so both misses the larger point and in the process proves it - Rails gave them a set of answers that are good enough so they don't need to delve deeper and can just focus on their app. Rails is not the only choice that does so. And people with broader skill se…

The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. * Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core. * React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web f…

Agree, and to go further (from the point-of-view of an outsider who is forced to do JS occasionally):

* should I use npm or yarn? Why do I see most package authors recommending yarn when npm is the default as far as I know?

* should I introduce Typescript to be able to handle complexity better?

* which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?!

* which test framework? Mocha? Karma? Jest? Cypress?

* should I use a bundler like webpack or just move on to esbuild? Vite? Deno?!?!

It's a nightmare every time I am forced to use JS (usually because of cloud services normally offering JS lambdas and nothing else)...

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#123

Have any of you tried .NET?

ASP.NET is great but it definitely comes under the same banner of 'too many choices needed' compared to Rails.

e.g.

Framework - Which .NET framework do you use (Core/LTS)? Do you use MVC, Razor Pages, Web API and Blazor (Server or WebAssembly) or Web API and an alternative JavaScript/TypeScript based frmaework?. Do you use JSON/XML/SOAP or gRPC? How do you serialize your JSON (NewtonSoft.JSON or System.Text.JSON)?

Database - Do you use Dapper, Entity Framework or just utilize a SQLConnection object manually (And then do you use System.Data.SqlClient or Microsoft.Data.SqlClient)? Which database driver do you you use?

Authentication - Do you implement this manually? Do you use something like Identity Framework? Do you use a third party provider like Azure AD(B2C), Auth0 etc. etc.? Do you use header based authentication, JWT's etc. etc?

Jobs - Do you create a separate service project or Windows Service? Do you use HangFire or Quartz?

Email delivery - How do you render your templates? Do you send via SMTP manually or do you use a third party API like Mailgun/Sendgrid etc. etc.

Folder structure - completely up to you, no real standards there.

Testing - Do you use XUnit, NUnit, MSTest, SpecFlow?

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#124

Earlier quoted context omitted.

I had similar feelings with Rails. Just memorize this billion convention and you are good to go. Also didn't help that running Rails on Windows was (maybe still is) considered a bad idea.

Is that still true with WSL?

No idea, but ideally that should solve it.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#125
Language X is better than language Y is blog posts are incredibly boring. No one actually cares what the author thinks - Rails devs will agree, JS devs will disagree, and no one else will care. But there's a great lesson here nonetheless.

When you're running a startup, and you're at that critical stage after launching when you're trying to get traction, getting people to see you exist is key.

reviewbunny sells a service for developers who want to get an email digest of their pending PRs at the end of the day. The notification emails that Github and Gitlab send aren't particularly clear, and setting up mail rules to mark them as important doesn't work for everyone, especially if you're working on multiple projects at once. So the author set out to make a product to solve that pain point. Writing a controversial blog post has got them to the top of HN's front page, which is awesome, and if the graph at the bottom of the homepage is correct it's won them 2 new organisations and a few new users since the article was posted. Amazing stuff. That's exactly what founders should be doing.

Maybe if it was a little less controversial those numbers would be higher, but there's no way to tell. Nevertheless, this is a fine example of 'content marketing' in my opinion. Well played. And I say that as a JS dev. :)

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#126

I think the author went too deep into details here, as this crowd is full of people who are going to be able to rip pieces of this article to shreds. But doing so both misses the larger point and in the process proves it - Rails gave them a set of answers that are good enough so they don't need to delve deeper and can just focus on their app. Rails is not the only choice that does so. And people with broader skill se…

Sure. And I think what makes Rails and Django shine is they have sound default answers. I’ve yet to see anything in Node that feels like a stable 1:1 replacement. Next.js is excellent, but you still need to sort out a lot of pieces on your own.

> I’ve yet to see anything in Node that feels like a stable 1:1 replacement

I’m not sure why there should be; for people who are happy with “good enough” default choices for a web app, Rails exists and makes the choice “Ruby” when it comes to language.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#127

I think the author went too deep into details here, as this crowd is full of people who are going to be able to rip pieces of this article to shreds. But doing so both misses the larger point and in the process proves it - Rails gave them a set of answers that are good enough so they don't need to delve deeper and can just focus on their app. Rails is not the only choice that does so. And people with broader skill se…

Sure. And I think what makes Rails and Django shine is they have sound default answers. I’ve yet to see anything in Node that feels like a stable 1:1 replacement. Next.js is excellent, but you still need to sort out a lot of pieces on your own.

I've never used Next.js so I decided to take a look. The first step in their Getting Started guide illustrates this pretty well...

  npx create-next-app@latest
  # or
  yarn create next-app
I would choose npx while my friend would choose yarn but there isn't a default or even an indication of why you might like either choice. We kinda just assume everyone already has a preference for npx or yarn.

This is really a Node or JavaScript problem and not an Next.js problem. Not that I have any idea how you might solve it. This is also just a single example and we tend to have these decisions at a lot of steps along the way.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#128

Am I the only one who simply looks at the business requirements when considering an SPA? Ive built music players, games, real-time chat apps, etc that would be very difficult or impossible with a server side rendering app.

I've interviewed a lot of web devs over the years. The distribution on this question is surprisingly bimodal.

One group of web devs is great at picking the right tool for the job. Simple web applications get simple solutions. The complex SPA solutions only get brought out for applications that require it.

The other group of web devs has learned one very specific tool and they want to build their career around that tool. The business requirements don't matter. They're going to use their favorite tool regardless of whether or not it's appropriate. The more complex they can make something, the better they think it will look on their resume.

The latter group can be valuable assets if you know that your application requires a SPA and matches the person's chosen specialty. However, if you're hiring a dev who wants to build complex apps and your company doesn't require complex apps, you're going to end up with unnecessarily complex apps. Then the person will use the complex app to boost their resume and leave for another company.

Fortunately, it's not too hard to differentiate between the two groups at interview time.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#129
post #67

Earlier quoted context omitted.

Sure. And I think what makes Rails and Django shine is they have sound default answers. I’ve yet to see anything in Node that feels like a stable 1:1 replacement. Next.js is excellent, but you still need to sort out a lot of pieces on your own.

I'm working on two inherited Django web apps right now, for the same customer. I wish Django has a default project structure like Rails. It doesn't. The only common ground between the two apps is that they are written in Python, use the same ORM and templating engine. One is a spaghetti monster of a zillion of apps that depend on each other (so the separation in apps is useless) and the database is totally opaque to…

If anyone else is feeling this pain please consider using this template https://cookiecutter-django.readthedocs.io/en/latest/

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#130

SPAs are the "Google-scale" of frontend tech. YAGNI unless you are Big (or trying to fleece VCs). SPAs are useful where the latency and overall UX of a button press can be translated to some tiny % increase in a KPI through A/B testing, etc. Where you want to track user behavior down to a pixel & microsecond, and wrapping every element in JS is the only way to get there. This is frankly irrelevant to 99% of projects…

> SPAs are not designed for developer productivity

Unless your app is big enough to have separate developers/teams for backend and frontend. In this case I'm relatively convinced by the argument that it allows you to decouple the two, so that all they need to agree on is the API.

Do you disagree? If so, how come?

Post reply on HN