Trying out Sails.js

[Jackolantern]

I am not sure how many of you have heard of Sails.js, which is an MVC framework for Node.js. "So what?" you might be saying. Well, there are a few things that make me very excited about Sails, and have me, at least on the outset, thinking that this could be the node framework I have been looking for. Express is cool and all, but it is very low-tech. Feature-wise, it just doesn't hold a candle to some of the big players on other platforms such as Rails, ASP.NET MVC, Laravel, Symfony, etc. Express is essentially a bare-bones web framework that looks a bit like an MVC framework. Where Express shines though is when others build onto its foundation to create something larger, in the exact same way that Express built on Connect. That is the case with Sails, where it has been built on the rock-solid foundation of Express and Connect, but it adds tons more features.

Some of the features in Sails that excite me:

1. It is built from the ground up to work with Socket.io. Getting Socket.io and Express to work together feels like pulling teeth. You basically have to make 2 separate sections of your program (one for HTTP, and one for Socket.io) and share functionality and data between them, with objects, setting socket nicknames, etc. Sails can funnel both HTTP and WebSocket requests to the same controllers, allowing you to structure real-time web applications almost as though there is no Socket.io. Security and access are automatically shared between Socket.io and Sails

2. Sails has a true ORM built in (called Waterline) that works well with both NoSQL and SQL databases using the same API.

3. You get a REST-based interface for free when you create a controller.

4. Built-in membership and roles. Instead of having to start from scratch every time to make a login system, you only have to customize what is there! This is a feature that has become fairly common place in modern MVC frameworks, but was sorely missing from most of the node frameworks out there.

5. It uses Grunt natively to automatically LESS compile, concatenate your client-side scripts, work with templates and more.

...and plenty of other stuff. But for me, #1 makes it more than worth a look. As easy as node and Socket.io make real-time web development, it was not perfect with the jagged edges of the two different technologies not coming together smoothly. This could make real-time web development a complete snap!

I will let you know how it turns out, but I am really liking it so far

[hallsofvallhalla]

Actually my first response was not "so what" it was "MVC RUNNNNN!!!" hehe kidding. I am just not a fan of MVC but I do try to get myself use to it. I will check out sail and see if JS can bring me to the dark side.

if you remember correctly I was the biggest anti Jquery guy around but I finally succumbed to its power.

[Jackolantern]

MVC seems like too much trouble at first, but then when you finish some complex controllers and views, you really see its beauty. Everything is so neat and tidy, which is the polar opposite of the mixed PHP, HTML and JS "all in one pot" PHP style. It makes things so nice and maintainable. It also allows you to easily swap in different views, such as one for mobile phones, another for mobile OS tablets, etc., all without rewriting any of the logic (something that is only getting more and more necessary). That isn't possible with all-in-one PHP pages, where the logic is connected at the hip with the display code.

But really, just like you said with jQuery, once you wrap your head around it and get used to it, you see the beauty in it. But the difference between MVC frameworks and jQuery is that you see immediate differences between jQuery and vanilla JS ("Hey, this code was 80% shorter with jQuery!"), whereas you really don't see the wisdom with MVC until you have to make a big change to your application, have to go back months later to make sense of it, have to create a new template for mobile, etc. Basically, you won't see the huge benefits of MVC until you are in maintenance. Like I mentioned, you do see some of it when you write something very complex, just to look at how neat and tidy it is, but you really see how it can save your project when something major changes mid-development and you can actually see clearly how it could be changed, versus the prospect of having to write 75% of the code over again

[a_bertrand]

MVC is mainly a marketing word... currently. As hardly any "MVC" framework really do work as an MVC pattern should specially on PHP where I saw none really working as the pattern describe what MVC is. 2nd because 90% of the cases you DO NOT need MVC, so it's pure overhead.

When it comes to how ugly PHP is, then I fully agree, yet PHP is not a tool I would use for professional web development

For the different views, beside honestly now the gadget we have render nearly all the pages without any problems, you could also simply use a CSS for it... and just switch CSS?

MVC is useful if you want to split the logic from the display, and have for example a rich client (standalone application) as well as a web, and maybe a web service too. But do you really need all the complication of MVC for that? Surely not, what is required here is the separation of the presentation with the business logic, which can be handled in a much simpler and cleaner way.

For the object... sorry... but since I use LINQ I don't want nor need any other "objects"

So yes I'm biased as ASP.NET with code behind is actually the fastest way I found till now, and... the code is clean and small. MVC for .NET? I don't like it even a tiny bit.

[Jackolantern]

MVC is mainly a marketing word... currently. As hardly any "MVC" framework really do work as an MVC pattern should specially on PHP where I saw none really working as the pattern describe what MVC is. 2nd because 90% of the cases you DO NOT need MVC, so it's pure overhead.

I understand what you mean about "MVC", as most web frameworks are actually "MVP" or "MVVM" or some similar pattern. The main part of the true MVC pattern missing in most web frameworks is the communication between View and Model. For whatever reason, that was considered bad when the pattern was imported to the web by Rails, and has been dropped almost every time since then.

For the different views, beside honestly now the gadget we have render nearly all the pages without any problems, you could also simply use a CSS for it... and just switch CSS?

That works for many cases, but some cases with complex UIs, a change in structure is actually needed. For example, there would be no way to make Facebook fully functional and mobile friendly. Most phones invisibly change to an app when you visit FB in their browsers, but that is because of FB's massive popularity and a desire to make it work. A smaller website would have a harder time getting that kind of setup.

MVC is useful if you want to split the logic from the display, and have for example a rich client (standalone application) as well as a web, and maybe a web service too. But do you really need all the complication of MVC for that? Surely not, what is required here is the separation of the presentation with the business logic, which can be handled in a much simpler and cleaner way.

I don't really see it as a lot of complication. Most professional web devs today use some kind of MVC framework or platform, and most speak of the productivity increases they get from them.

So yes I'm biased as ASP.NET with code behind is actually the fastest way I found till now, and... the code is clean and small. MVC for .NET? I don't like it even a tiny bit.

I like .NET, but I do not like ASP.NET Web Forms. Any .NET web development I do, I use ASP.NET MVC. I want to write the HTML, Javascript and CSS myself, and don't want .NET to stick its hands in it at all. Also, Web Forms suffers from the same problems that plague Windows Forms, namely the ease of slipping into the Smart UI Anti-Pattern. The weight of View State is also quite a serious problem, when the problem has much better modern ways to handle state. Web Forms was designed in the late 90's when almost no one understood web development, but over a million devs understood Windows Forms in VB6, and also when Javascript was not an extremely important part of the web (unless you wanted to add a snow fall effect to your page lol).

I would really, really suggest to give ASP.NET MVC a serious try. You will find it liberating for websites that require a ton of client-side scripting to finally be able to dictate all of the Javascript and HTML yourself.

[a_bertrand]

I gave ASP.NET MVC a serious try, but I can tell you it simply fails at what Web Forms shines: re-user web components. I wrote many myself, like smart lists, drop down selections, date pickers and many others. Result is that in nearly no code lines I have the tools I need. MVC cannot reach that even remotely. Session an issue? Maybe for a remote site or a mobile phone. As I work for intranet sites, session views can be as huge as they need, I could not care less. BTW I discussed with many companies developing in ASP.NET before taking the choice of web form.

Plus honestly, I really really hate jquery. It's one of the worse lib I ever saw. So somehow selling jquery with ASP.NET MVC? Yet another reason I want to stay far away from it.

[Jackolantern]

Well, to each their own I guess. Although I can see some value in Web Forms for intranet sites that mainly exist to connect to databases, as Web Controls could save a lot of time there. But for public-facing websites, it is MVC for me all the way. And I love jQuery, and think it is one of the best things to ever happen to Javascript

[a_bertrand]

Well I know you like jQuery, I simply can't stand it. The syntax, the inconsistency, and the poor readability are the main things which keeps me out of it. Plus honestly, browser compatibility is not an issue so much anymore, so the need of an abstraction layer is less of an issue it is now than it was 5 or more years ago.