Comment by curveship | Hacker News Reader

Comment by curveship | Hacker News Reader

It concerns me that the selling points of Meteor are the same as the old selling points of ASP.Net.

- Both seek to make the divide between server and client "seamless", marshaling data back and forth so that you can "call" server code from the client and vice-versa.

- Both tout the ability to do all your development in a single language

- Both claim impressive gains for RAD

ASP.Net had some impressive demos for its time. But as we know, the warts emerged:

- as apps grew larger and more complicated, the claim of "seamless" integration started to break down. The background traffic increased until the latency became untenable. Now you had to diagnose problems in a system that had been designed to be "invisible," meaning it was hostile to exploration. Why will Meteor be different?

- The "one language" (VB.Net for ASP.Net, before C# became big) wasn't so hot a foundation. One word: Javascript.

- It was an island. The background data-marshaling framework meant that it didn't play well with other software unless that software had been explicitly written/adapted to work with ASP.Net. ASP.Net wasn't bad at first, but the vaster ecosystem of the web quickly distanced it. What's the upgrade path for a Meteor app? What if I want to use Angular with it?

ASP.NET enabled a lot of certain types of developers to quickly drag-n-drop web apps just like they did with VB Windows GUIs. The amount of code needed was pretty cool. Sure, it resulted in a less-than-ideal webpage, but it worked. VB.NET wasn't really a foundation; it had major changes from VB6 and had feature parity with C# (and more in some cases). Javascript is by far a much worse language. What should we expect from a 10-day design?

If this guys is going off about how it shaves a week or so off a 5 week project, problems that appear on bigger apps might not be high on his priority list.

I wonder if Meteor will end up introducing security holes like ASP.NET, as developers forget there's an abstraction and clients can't be trusted? (In ASP.NET, things like being able to screw with viewstate or fire events for disabled controls.)

I still have the hope for a unified platform. But I'd much prefer it to be on a solid language that compiles down to JS. I'm not sure it's an unattainable goal. I think you nailed it with "seamless" and "invisible" - abstracting major things like client versus server, or local versus network, can really end up biting developers.

>I wonder if Meteor will end up introducing security holes like ASP.NET, as developers forget there's an abstraction and clients can't be trusted? (In ASP.NET, things like being able to screw with viewstate or fire events for disabled controls.)

This is a thing for Meteor already. For example, if you have the insecure package enabled, you can can make changes directly to the database from the browser console. However, this particular issue can easily be detected prior to deploying to production.

Insecure is there to help speed development when you are getting started.

All frameworks can do their best to compensate for security holes, but ultimately people need to pay attention to it. That being said, Meteor offers a call method and code runs on the server - if security is a concern then you should pay attention to what happens on the server.

I've not used Meteor. How exactly does "insecure" help speed development? Certainly any code you write with it is worthless, right? I mean, before production you need to remove it and rewrite it using another method, so what's the point? Or do you mean it's useful on the sysadmin side, as a REPL-like data access console?

From meteor.com:

>By default, a new Meteor app includes the autopublish and insecure packages, which together mimic the effect of each client having full read/write access to the server's database. These are useful prototyping tools, but typically not appropriate for production applications. When you're ready, just remove the packages.

It makes it easy to run DB calls from the chrome console to insert and modify test data

While you are right, my view is simply that any developer incapable of understanding the difference between client and server has a snowball's chance in hell of actually creating something secure. Meteor may abstract some of the drudgery of client-server communication, but you still have to know the difference - both for security and implementation.

Similarly on the Java side you've got JSF which is basically ASP.Net ported to Java. It was a dumb idea when ASP.Net did it, and it was still a dumb idea when it was ported to Java. Now we have the same dumb idea ported to Javascript. Also as you point out, Javascript.

Thanks but no thanks, give me a proper REST API on my server, and a good JS framework on my client, and I could really care less what language the server code is done in so long as it's easy to build the REST services I need in it.

So it is ok to go build a node.js REST api and slap Angular.js on it and somehow that is better?

You really should care what language/framework the server side is built in because someone has to work on it...

I had the great privilege of working and maintaining a few JSF applications for a year or so when I first got into my job. -_-. I even had a greenfield project with it. It's probably the worse thing you can use, and after some asking, pleading, and convincing the boss we moved to Play 1.x. That turned to be a wank fest with the whole Scala and Play 2 thing coming in a year or so later. We ended up just going to the source of all good MVC frameworks and landed on Rails, with a move into Node for a few months before Rails.

I tried Meteor a few times and the whole thing just reeks of JSF. I wont touch it with a ten foot pole.

On the other hand Rails and Ember really flow good together. I was more of an Angular fan, but the whole Ember integration is great. Rails makes it really easy to do nice API's without a whole lot of boilerplate. Database handling is awesome. Migrations are nice. Lots of gems. I feel like someone is holding my hand, while with Node I felt like I was holding my breath the whole time. If that makes sense. It was like a sigh of relief when we moved to Rails.

The whole context switching thing is overrated IMO.

How does a story entitled, "How Meteor will kill Ruby on Rails" turn into a bitch-fest about ASP.NET?

But I have to admit that it is pretty funny that comparing a framework to ASP.NET is apparently the nerd equivalent of insulting someone's mother.

Of course ASP.NET was closed source, and from Microsoft — Meteor is open-source, and is being driven by a small team.

What does that have to do with any of the points raised?

I have more faith in open-source community to fix warts vs. closed-source Microsoft. I did ASP.NET back when it launched, and Microsoft wasn't setup to really listen to developers like the Meteor team is.

Actually, Microsoft did listen to their ASP.NET developer userbase. And ASP.NET developers loved them for it. And yet, despite Microsoft listening to their users, we're still not enchanted with ASP.NET... what gives?

Lets say a framework's user base consists primarily of language-specific consultancy shops that really desire tools for rapidly prototyping applications. And the framework authors listen to these users diligently. You'll likely have a product that's really good at rapidly prototyping applications inside a consultancy. What about people who aren't language-specific consultancy developers? Well if you have a similar use-case you'll surely be happy!

Meteor and Rails strike me as Apples and Oranges - Rails is a general purpose framework that assumes a separation of systems between client and server (And optionally separation between server and database if you forgo Active Record). Meteor assumes you want a tightly coupled, real-time, rich JavaScript web application.

The author assumes Sauce for the Goose is sauce for the gander... but judging by the lack of ASP.NET around here I'm not sure that's the case.

As someone that's been building high traffic applications on ASP.net for 11 years I generally stay out of threads like this. There is a ton of ill-informed (and more often than not blatantly false) asp.net bashing that goes on on this site. I see so much of it I generally just roll my eyes instead of hitting the reply button.

You can't use the silence of developers like me to prove a point when any pro asp.net content posted here is met with hostility.

ASP.net has an "easy mode". Easy mode is for small sites made quickly. If you're dragging and dropping, you're using easy mode. If you're only using the server controls provided, you're using easy mode. If you haven't extended or replaced any of the provided subsystems, you're using easy mode. I'd prefer developers from other platforms stop making comparisons between their platform and easy mode asp.net as if they knew what they were talking about.

ASP.net is a tuner's platform. It is completely modular, and anything you don't like can be replaced with something custom suited for your business/performance needs. This goes much deeper than custom server controls. You can look at the development of ASP.net MVC as an example.

If you want an easy framework to master, ASP.net is not the place for you. If you want something fast, scalable, strongly typed, customizable and built for large applications; you should have a look under the hood.

Those who haven't spent time getting intimately familiar with ASP.net's innards really have no place to comment.

In November W3techs.com's survey of the top 1 million web servers based on alexa.com traffic numbers found 18.6% to be running on ASP.net.

There may be a few more ASP.net developers out there than you assumed.

http://w3techs.com/technologies/overview/programming_languag...

it means if you have to explore some "invisible" process, you can see exactly what it does and inject your own code if you want to change it.

Reply on news.ycombinator.com