Actual line printers were pretty quick and wouldn't have been running for long periods of time, and were likely to be tucked away in a back room somewhere. Now get a few 30-character-per-second DECWriters buzzing... And those were a vast improvement over the 10-CPS Teletypes that were the rage before video terminals were affordable.
A former coworker had a story from when he used to service those things. He was doing a cleaning and was tossing the solvent-soaked rags into a garbage can on the other side of the printer door. Someone came by and tossed a cigarette into the can - managed to blow out quite a few ceiling tiles. He was always a bit hard of hearing but I never determined if it was connected to this incident or not.
I'm not sure if you're talking about the pain of going back to testing ruby / rails after using mocha / node, but I feel that specific pain, especially on projects with old-school Rails purists who insist on Test::Unit style. Switching to rspec gives you nested describe blocks with shared setup and teardown steps, as nice as mocha. Minitest has this BDD style built in too, but somehow the way Rails ties it in makes it difficult or impossible to take advantage of.
You know, it's possible to have a conversation without having an argument. It is possible to listen to others. Not everything in life, or indeed on Hacker News, is a debate to be won. Sometimes we're just sharing our human experience.
There is a difference between web pages and web applications, and Meteor is built for the latter. There is no such thing as a progressive enhancement path in many cases. If your firewall (?) strips out JS, then you are on a broken network.
Yes, there is a difference between pages and apps. You should still not send only empty body tag. Click link, see blank page - how am I to know what kind of page it is? I'm really only referring to documents (like www.meteor.com, I presume - I can't actually read it from this computer as it's a blank page). Even on "web apps", there should really be at least an error indicating that the app only works with JS, or maybe a link to a fallback/alternative if appropriate.
Note: a search page is not an "app". Progressive enhancement works just fine in almost every case that isn't a purely interactive app (i.e. google maps or a game). It is trivial to render, as needed, the HTML template with the header/footer, or a layout-free snippit, or simplee JSON, or whatever else is needed. This was basically zero extra work in Rails years ago, so I don't see why it can't be done now.
As for stripping JS, that is easy, and done for security reasons. Yes, this requires a custom cert so the firewall can MITM the connection, which most businesses do anyway. No, this does not make it a broken network. Javascript is optional, and always has been. ( http://www.sitepoint.com/javascript-dependency-backlash-myth... )
There is actually nothing in meteor which states that you have to have only a body tag in your html. In fact, you can very simply render html headers, footers, and other static html without javascript. You can also handle 404 and send static pages for such appropriately. If someone has misinformed you, do take their opinion as nothing more than nonsense.
Now if you happen to run across a site which does not handle this properly, that is not shocking in any way. I have found that generally speaking those who disable javascript often complain about sites which extensively use javascript. They say things like "you can't assume that everyone has javascript enabled", "javascript is a security hazard and you can't expect me or anyone else to run a site with such a blatant vulnerability", and "how dare sites use such shotty technology to give an experience, they need to realize we need the same experience but without all of the vulnerabilities". The list of complaints go on and on.
The reality of the situation is this: as someone who makes consumer applications for profit, most of us don't care about you. If you are willing to turn off javascript, you are probably not my target user. If you work in an organization which does something so stupid as to break ssl in order to commit mitm attacks on your own employees in the name of security, you are probably not my target user. I do this for profit, not to cover ever last edge case known to man for every "security conscious" consumer of the Web. I worry about the security of my actual users. I worry about giving them the best possible experience. I care that they can use the product and enjoy it and will come back again and again. Javascript is optional for you, but it is not option for my applications. Hundreds of thousands of my users don't seen to mind.
That's actually very informative. ?I guess www.meteor.com is one of those sites that doesn't handle it properly? I? have no idea.
> Hundreds of thousands of my users don't seen to mind.
Really? Have you asked them?
Hundred of thousands of your users probably have no idea whatsoever what their browser is doing, and it is disingenuous to say that they "don't mind" - especially when javascript is used for things like tracking reading times and other things probably call "analytics" and a lot of us call "spying".
> I worry about the security of my actual users.
Apparently not - you just make sure your users can only be people who know nothing about modern network security.
Remember, I'm not saying javascript applications are bad or that you shouldn't write them[1]. I'm saying you shouldn't leave your precious "user experience" in the case where javascript is not available as a totally-useless, non-informative blank page. Which many sites have started to do, www.meteor.com included. Thqt''S IT. All this arguing about javascript is missing the point.
[1] At most, I only suggested that a lot of the time what is being made is not an application", but a fairly simple document. The only reason javascript could be needed (isntead of progressively enhanced) on something like a simple search page is if you are trying to run spyware (such as google-analytics) in the background, behind the user's back.
Here's Redis Labs' (my employer) comparison table of cloud services for your reference: https://redislabs.com/redis-comparison. It's only slightly outdated (missing the MongoHQ-cum-Compose.io offering) and we'll probably add it in the near future.
But you can't have clients directly connecting to the database, their sockets still need to flow through an application layer where you have your business / application logic. Unless you start putting application logic into the db?
Your right about this. Couchbase solves it by putting a sync gateway in front of a couchdb connection. But this makes things hard to manage for the reason you mention: business logic inside your DB. All your rules about access control and users are actually derived from values in your couchdb documents. Its not pleasant to design or maintain.
> Refactoring across the call stack is orders of magnitude easier than refactoring across a socket.
That's assuming that things haven't become deeply coupled within the "call stack". Separating things across a socket often forces a separation of concerns, which does tend to make refactoring easier.
In my experience communications across a socket does not force a separation of concerns. It doesn't even encourage it.
Heck, because asynchronous communication in a non-deterministic environment is so hard to deal with, my experience is that such communications encourage shortcuts to be taken, so yes, I think it encourages tight coupling.
The only thing that somewhat encourages a separation is having different people responsible for different modules and because people are selfish, they'll fight for their components to have less responsibilities, not more. So it becomes a territorial thing. But this happens only if you have seniors that know what they are doing, otherwise rookies or less competent folks end up cooperating to "get things done".
Weird reasoning, that. I hardly see how a selfish, "territorial" and noncooperative approach could benefit anybody. Sure people might cooperate, but that doesn't mean they will take shortcuts and mess things up.
> That's assuming that things haven't become deeply coupled within the "call stack".
Yep; Monolith or SOA you still have to write SOLID code :)
> Separating things across a socket often forces a separation of concerns, which does tend to make refactoring easier.
It /should/, and if it does now your changing more than the one variable of "invoked across stacks -> invoked across socket", and are more likely to introduce a regression :)
This is why AppEngine modules are so awesome. Have a route that takes on the majority of your traffic? Slice it off the main app declaritavely to its own cluster of machines.
