Show HN: Realtime Chatroom Built with Laravel and VueJS | Hacker News Reader

Show HN: Realtime Chatroom Built with Laravel and VueJS

github.com

53 pointsazazqadir20 comments

From the article that this code is from:

> In today’s article, I am going to create a chatroom using Laravel 5.4, Pusher and VueJs. Since these tools are popular and almost every developer has heard of them, I will skip the theoretical introductions and discussions and go straight to the fun part.

I, uh, I don't think almost every developer has heard of them. Even making the names links would help.

I'd say if you're a PHP dev, you'd know what Laravel is. And Vue is up there with React/Angular in popularity for Javascript devs.

Pusher is the only odd one; You'd probably only hear about it if you've looked into real-time communication technologies.

I must be so old.

I spend all day sitting on an IRC style 'chatroom' with a bunch of friends, that was written about decade ago.

It uses a combination of javascript ('ajax') on the client side, and crappy ASP on the backend (because the only server at the time that was available was a Windows server).

The comms is very simple asynchronous polling and formatting/parsing javascript. In fact the only updates over time have really been all client side to take advantage of new browser features. It works through firewalls and proxies (which websockets still do not) - basically anywhere you can see a modern webpage.

My rambling point is... you don't need all these frameworks to push a message to a server, and fetch back a list of new ones. In fact for low volume handful-of-users chat traffic you don't even need a database (gasp!).

I know we should all avoid re-inventing the wheel where possible, but are you (not 'you' the OP, but 'you' the fictional reader) really a web developer, if all you are doing is gluing ever changing frameworks together ??

You're friends were replaced by chat bots long ago. We've all been watching you like a mini ascii truman show.

I had suspected that actually.

Then that's good, because you already understand perfectly what is being built so you can focus on the how. Which is the point of the article.

Most applications use SockJS or Socket/Engine.io instead of raw websockets, so you get the latency benefits when websockets are supported while still functioning (probably better than AJAX on a timeout with long polling) when they're not. I know your old architecture was simpler, but fetching periodically from a server is high-latency and bandwidth inefficient.

Most people are here to learn, to build something more advanced, and/or to build something prettier. No need to condescendingly pretend like everyone else should be judged by your needs and nostalgia in a chat room.

I wasn't. I was challenging the modern need to just bolt pre-existing frameworks together. I WAS hoping for a discussion about it. Maybe my intent was not clear. Apologies.

I'd welcome other opinions, but I find Laravel's support for 3rd party tools/frameworks to be genuinely superb. They save me time on ramp up and implementation, which is often the single biggest bottleneck for shipping side projects.

Pusher is one of many Pub/Sub mechanisms laravel supports [1], and Vuejs is included "out of the box".

Point is, these frameworks aren't exactly bolted together any more or less than any other software integration.

[1] https://laravel.com/docs/5.4/broadcasting

I'm not seeing a valid axiom to base that point on, either. I can use a framework and release an MVP in a month, or I can spend an entire year writing the equivalent of a framework and then release an MVP a month later (my custom framework lacking the battle tested stability, security, and peer review from a formal framework's community). Multiple frameworks exist to cater different projects and different opinionated teams. Laravel isn't even a fully reinvented wheel, it uses a lot of symphony components, it is compatible with a lot of generic PHP libraries, it uses some standard tooling like composer and webpack. By not writing my own custom framework, I can pass off my project to another team or my client can hire any random PHP developer.

It's not a "here's the best way to make a chatroom" article.

It's a "here's how you can use Laravel and Vue" article.

> and crappy ASP on the backend (because the only server at the time that was available was a Windows server).

I don't think there was ever a time that people didn't have alternatives to windows server and ASP.

Maybe there was a time that ASP was more popular than the alternatives, but I personally haven't observed such thing.

I didn't write it - so I do not know the logic behind using ASP.

I think he quite literally means the only server available to host it on was a windows server, although I still don't see why that limits you to asp at all.

Oh.. my bad.

Reply on news.ycombinator.com