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

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

reviewbunny.app

Post reply on HN
Print view View original

211–220 of 490 posts

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

#211

Post by BMorearty »

Great post. This is one reason I love using Rails, the fact that it makes so many decisions for you—and with good defaults. Before Rails I had the exhausting experience of spending weeks making tech decisions just to start a project. (I’m also a huge JavaScript fan but for different reasons.)

Small nit about one point in the post:

> As far as I know, serverless platforms don't support WebSockets

I’ve spent the last couple weeks deep-diving on Cloudflare Workers. They have good support for WebSockets. And if you need your WebSocket to maintain state long-term, the server side can use a Durable Object.

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

#213

Post by Oddskar »

1_player wrote: post #148
bengale wrote: post #138

Earlier quoted context omitted.

Yeah it feels like this NextJS opinion is very out of date.

I've spoken about my dislike of next.js a few times, and it's mostly centered around its documentation. It is decent, but it is no way as complete as an established framework like Django. Have you ever compared the depth of the two? I'm on mobile, just read and compare, I don't know, the routing API docs for both. Also the APIs are very simplistic, I haven't used it in the past few months when I quit my job, but I vi…

I think in general it's a very tall order to compete with the documentation of Django. It's pretty much world class. I wish more projects had such good documentation.

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

#214

Post by Oddskar »

Alex3917 wrote: post #194
trimbo wrote: post #182

Earlier quoted context omitted.

> 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. Do people believe this about Angular? Not primarily a front end dev, but in my limited experience with React and Angular, it seems like Angular's strength is that it provides more structure for scaling to larger projects.

Honestly Angular is great even for startups. With the current state of the the framework and the way the Angular CLI bundles code, it's pretty hard to break 90 on PageSpeed Insights (at least without pre-rendering). But it's also not that difficult to get in the high 80s, which is pretty good for a SPA. And it should only be getting more performant as they put more working into optimizing it. It's easy to learn, the…

> And it should only be getting more performant as they put more working into optimizing it.

You say this like it's not an 8 year old framework. I wouldn't have such high hopes for it rising significantly.

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

#215

Post by bredren »

pmontra wrote: post #67
coffeefirst wrote: post #28

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…

I have not had as much of a problem with structuring django projects. I agree there could be better documentation recommending best practices.

There is a very good talk from Dan Palmer from Djangocon 2021 called "Scaling Django to 500 apps" that gives helpful advice for project layout in a django app that may only have a few or several apps:

https://2021.djangocon.us/talks/scaling-django-to-500-apps/

That said, if we're going to dig on Django, it lacks typing, core-based API patterns and any embrace of modern front end. There are positive signals though, releases are coming faster and there is some real talent on the tech board right now.

I do think django and python in general are in a defensive position to hold the future of backend webdev compared to node / deno. However, there's still plenty of opportunity to compete for developers.

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

#216

Post by dragonwriter »

1_player wrote: post #69
codingdave wrote: post #7

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…

> Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer.

If you can settle on a good enough batteries-included framework without analysis paralysis, you can make the individual as-needed decisions about libraries without it. It's not a problem of a higher order.

If anything, it's lower-pressure, because the cost of a wrong choice is much smaller.

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

#217

Post by ubercore »

pphysch wrote: post #146
bauerd wrote: post #131

Earlier quoted context omitted.

Have you tried to implement interaction-rich applications such as calendars or text editors with server-side rendering? You won't be able to recreate the UX an SPA can afford, regardless of revenue.

Yes, I have. With a proper backend language like Go it is trivial to manage concurrent WebSockets and arbitrary data across them.

This sounds more complicated to me than just using React plus an API backend.

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

#218

Post by mrkurt »

tylergetsay wrote: post #76

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.

The state-of-the-art in server side is simpler and, arguably, more powerful than SPA + APIs.

We wrote a demo social music player with Phoenix LiveView: https://fly.io/blog/livebeats/

And Remix has another great take: https://remix.run/docs/en/v1/tutorials/jokes

PHP is amazingly capable too: https://laravel-livewire.com/

Even Rails + Hotwire go a long way.

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

#219

Post by com2kid »

EnKopVand wrote: post #60

I don’t fully understand the issues people have with JavaScript and especially React. Maybe it’s because we invested some time in setting up a baseline project with ESLint, prettier and a TSConfig that makes for an entirely fascist way of doing TypeScript that just happens to always work. Maybe it’s because we don’t NPM install a lot of things, but instead take what we need and build our own packages (riding free on…

React is great until you have non-trivial state management then life starts to suck again.

The # of react apps I've seen where every key press entered into a form takes 200-500ms is super high. Heck the first version of Work At A Startup here on HN had input box latency problems that looked a lot like what I see in React all the time.

It is funny because Redux's religious adherence to a const store makes no sense. Sure it provides a cool debugging trick where you can rewind things, but other than that it seems to just provide an endless hole of performance issues with people using the spread operator incorrectly.

C# and Winforms lets me pump out CRUD apps at literally 20x the speed I can in React. What takes me a day in Winforms can take a month in React. Wish I was kidding there. I once prototyped a website in Winforms, less than day.

I spent 3 days getting a date time picker working across all browsers desktop and mobile with accessibility support working. (Only because Safari doesn't support datetime pickers....)

Web dev sucks compared to desktop development. Hell Java + Swing had higher developer productivity than web dev.

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

#220

Post by jeremyjh »

pphysch wrote: post #209
jeremyjh wrote: post #178

Earlier quoted context omitted.

Yeah. I've done the server-side thing quite a lot. I don't like it. You always end up with "little bits" of javascript code strewn about in your DOM doing adhoc manipulations based on user events, server data arriving etc., and so the actual behaviour of your app is more difficult to reason about. Also, I want my users to have a nice experience and enjoy using the app, even if I don't have a KPI to represent that ben…

I don't follow this logic. Why do you end up with JS strewn everywhere? Sounds like poor organization practices. 1. User arrives at a page where a real-time widget may exist. widgets/mywidget.js on that page. 2. User triggers mywidget.js by pressing a button or just existing. It dynamically creates the widget elements, requests a secure websocket, then sets up input/output handlers. 3. Done. mywidget.js could be big…

I'm not talking about how my javascript source files are organized, I'm talking about how the functions are dispatched from the UI. That is done with event listeners strewn about in the DOM.
Post reply on HN