The world needs a better spreadsheet - <AUTHOR> http://blog.voyager.vc/the-world-needs-a-better-spreadsheet/ <comment><USER2> Eons ago, I worked for Lotus Software (way before they belonged to IBM) on an exiting new product - their flagship Lotus 1-2-3 spreadsheet product, in those days the preeminent spreadsheet offering in the world, ported to the IBM mainframe.

I travelled around Europe as we sold this to large corporations who wanted the power of the spreadsheet, but multipled by a gazillion times and made multi- user.

Almost every customer was so receptive and excited, it was a fun and job and easy sell.

But later, we learnt that those customers were in fact the early adopters, and Lotus never did manage to cross the chasm with that product. Later Microsoft produced Excel and..well the rest is history.

My conclusion: the world doesn't need a better spreadsheet. Existing spreadsheet technologies are good enough for the hokey, half-baked things that people like to build with them.

<comment><USER3> I like that you're bringing up Lotus, but I was thinking of a different product: Notes.

It's from another digital software age and from experience, hard not to think of the applications created with it as archaic monstrosities, yet there was something there.

In many ways it was what the OP is talking about: a networked formbuilder that allowed for people with technical skills roughly equivalent to that of an Excel superstar to build actual line of business apps.

For those same reasons, it had lots of issues. Often a spreadsheet is the right choice, maybe not when it gets to be 200MB and corrupts itself because multiple people are accessing the same file across the network.

Notes apps worked until they didn't, but are still kind of fascinating in their awfulness.

<comment><USER4> Apps like Lotus and Access get a bad rap that is unjustly deserved. People did a lot of amazing things with those applications.

The presence of zombie Notes apps that spew out of control is more a statement about IT than the platform. My mom, not a power user, was a public health nurse. She put together with a sophomore intern what grew into a good sized disease outbreak tracker after IT failed to deliver. All in Notes.

The IT idiots discovered it and got all puffy. They siphoned off funding and stuck its "enterprise" replacement into some portfolio process. 5 years later and $5-6M spent they launched a replacement that didn't quite do what it needed to do. She retired almost 10 years ago, and that little app still lives for a few use cases.

</comment></comment></comment><comment><USER5> _Perhaps, In the end, the best piece of software is the one you never had to build in the first place._ \-- The Article

 _Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?_ \-- SICP

I think the real uncanny valley here lies in maintaining software, not designing it. Business needs change over time and software must adapt.

I think the best option is to build your own software. Understand it top to bottom and make it do exactly what you need to do. Sadly this is not possible for most people.

The next best option, however, is not to spend $3,000 on something written over a weekend that won't be supported down the road. The best option is to go with the Salesforce solution.

My first programming gig (in high school) was automating a process that involved manipulating index cards and doing some basic math. I also trained them on how to operate, maintain and extend the system. The end result worked fine for a few years, until it was eventually replaced with some elaborate proprietary system that cost about as much every 3 months as the whole system I delivered. But that system came with ongoing support that obviated the need for any in-house expertise. So they felt the additional expense was worthwhile. And I was happy not to have to take the support calls.

Edit: And ultimately both systems were more accurate and saved time over the manual process.

<comment><AUTHOR> OP. This is a great point. The activation cost for you to respond to support calls is probably more than the company would be willing to pay you. Which is why SaaS businesses with support teams that benefit from scale are the de facto model for these businesses.

I think there's a version of something like Microsoft Access that can take away a lot of support requests.

I get a ton of requests related to lists of collections within the app, which could be maintained by the users themselves.

<comment><USER6> > I think there's a version of something like Microsoft Access that can take > away a lot of support requests.

Yes, and it's called Salesforce (or Dynamics if you like more pain than Salesforce already causes).

I have better things to do than write a full front-to-back webapp to organize garbage scattered around in spreadsheets, so it's been a lifesaver since I can create a new object or field in a couple clicks (and if I need to write some custom UI or backend code I still have the option to do so).

</comment></comment></comment><comment><USER7> I have been reading HN for more than 3 years. It is like an addiction. I have never felt smart enough to comment something but honestly, this is the worst piece of literature I have ever read.

The writer is just rambling on irrelevant stuff while trying to be smart and promote himself and his company.

It's not even good marketing.

<comment><USER8> Agreed. I'm not sure exactly what I read, but I couldn't piece together a single coherent line of thought as we jumped from sketchy individual developers to requirements gathering, something about UX, valleys, zombies, Salesforce as a CRM (except it can do anything really 'cause it's a platform), to the closing statement about perhaps not building the application you thought you needed. And what did it all have to do with spreadsheets, or building a better one?

</comment></comment><comment><USER9> I'm seeing a lot of hate for spreadsheets here.

First, to state the obvious: in the time your least-favourite Excel sheet took to grow from simple time-saver to sprawling Cthuloid monster, it has probably saved _multiple person-years of effort_. You could spend the next six months rebuilding it all "properly", and it's still comically positive ROI.

Spreadsheets are also a unique, top-level category in computing as a whole. By my count, there have only ever been three schemes of interaction with computers (with any significant adoption):

1\. Shrink-wrap. Use the software you've been given. Read the manual; that's what it does, no more.

2\. Programming language. It's text, it's got syntax, it's got the same basic constructs as any other programming language. You know they're all the same, because once you know a few languages, you can start using a new one in an hour or two.

3\. Spreadsheets. Visual interaction, scaling smoothly from "simple calculator" to "this is the backbone of our whole business".

Spreadsheets really are _that_ fundamental a discovery in the field of computing. Give them some love.

<comment><USER10> But why not word processors or presentation software (PowerPoint)? How about Photoshop? That's pretty big.

Edit: oh, you're not computing something so much as you're using shrink wrapped software to build documents, presentations, or manipulate images. So, not quite the same.

As for programming languages, I disagree. You don't go from only knowing say Python, PHP and Java to being able to use Haskell in a few hours. There's a substantial learning curve in being able to use a sufficiently different programming language. And no, "Hello, World" or typing in a few simple commands from a tutorial don't count.

Do you suppose the a C programmer is just going to be building a meaningful Smalltalk or Lisp program after a couple of hours? Or that a Javascript programmer is going to be whipping up C++ applications in that amount of time?

<comment><USER11> I've seen orgs run on Excel spreadsheets: one electric utility I worked for described their load in one massive Excel sheet. Where I think this analogy falls apart is that so many spreadsheets come to depend on macros (which my experience did, via ODBC), which makes them a meld between 2 and 3. I've definitely written systems at level 2 -- at the same company -- that have had way more ROI than the spreadsheet based system that was previously employed, but the spreadsheet could have employed macros to do the same thing.

</comment></comment></comment><comment><USER12> Spreadsheets are the poor man's data processing pipeline; they ship with a wealth of numeric and data munging functions and give you an easy-to- understand visual representation of your datastore. You can use them to crunch numbers and graph, but also to implement fairly complex business logic, and they accomplish this within the confines of an application you probably have already bought anyway. They're the epitome of the entrepreneurial spirit you need to survive adversity in the SMB space.

Spreadsheets don't succeed outside of pure numerical calculations because they're _that good_ , they succeed because they're versatile and ubiquitous, and everyone already has Excel or Google Sheets. If _everyone_ already had, say, Sharepoint, or even some drag-and-drop no-cost rapid application generator that requires zero sysadmin skills to run, that would be the new baseline.

<comment><USER13> I agree. The problem is also that most people who are running SMB aren't experts at growing their data model. Over time, the owner needs new objects (rows, columns, sheets, etc.) and new things that need calculated and tracked _BUT_ they also need to associate these new things to the old things. They are not going to be able to renormalize the data model (they don't know they have). They make new sheets or Excel files and do the best they can. It is flexible and can do whatever they want but that doesn't make it more efficient. I don't think that most of these people need new or custom software. They need someone to come in once a year and help them re-optimize their processes against the new reality. Excel might be enough but there has to be an investment in making that an efficient tool.

<comment><USER10> Sounds like someone should come in and turn that into a database that feeds excel.

</comment></comment></comment><comment><USER14> I agree with this in premise, and had a very similar idea with a friend earlier this year - that many of the business apps out there are really just CRUD apps.

The main piece of feedback that we got when pitching this idea was that you're going to end up as a master-of-none. Yes, we could give you the tools to set up Customer, Ticket, etc. objects. But in order to win over Zendesk, you're going to need all of the features they provide. Chat, ticket queues, automation, etc. Business users also don't want to be architects - a turnkey solution that solves 80% of their use case is better than a blank slate that they have to start thinking about schemas, relationships, etc. The old saying "nobody ever got fired choosing IBM" can now just as easily be applied to VP of Sales picking Salesforce.

That being said, there ARE tools to do this: Quickbase (enterprise) and Airtable come to mind. I'm curious if the author has looked into using one as their base instead of Google Forms/Sheets.

<comment><AUTHOR> OP. This is an idea I've been going back and forth on for a while.

I have checked out Quickbase, Airtable, Ragic, etc.

What I've noticed is that I always want the ability to go to code when I need to. My clients are all on Rails apps today, and I'm happy with rails as a dev solution. And, I don't want to give up that flexibility.

However, there are use cases where I want to just use a form builder UI to manage a data model. I've been using [http://form.io](http://form.io) for that recently. You use a form builder to generate a UI and an API simultaneously and submissions are stored in Mongo. And, I can build the app as I want using their API.

I think that paradigm is the future, it just needs more refinement.

<comment><USER14> Ah alright - so definitely more aimed at people who can code. Ours was more focused at end-users.

That is one area where Salesforce shines. APEX and Visualforce can get you just about anything you may need for customizations. I'm sure something similar will pop up, but then people will complain about having to sell your soul to them, too :)

Workato is another nice tool to augment Quickbase & Airtable. It's like Zapier, but allows you to add some code (Ruby in fact) to do custom hooks.

I guess it really depends on how complex you need to go, which then brings me to my point about being master-of-none - at that point you're losing your abstraction and essentially building a custom app.

<comment><USER6> Salesforce is a great solution for stupid CRUD apps that require some custom code here or there. A year ago I started with 8 users, now I'm at 40 and counting - I don't have to waste time developing a front-to-back web application to keep track of garbage that was stored in spreadsheets, and my users get rapid turnaround on most changes (hey, add this new object or field please!).

And if your users don't need to access a lot of different "types" of data (objects) the $25/mo "App Cloud" license is a cheap way to get going.

</comment></comment></comment></comment><comment><USER15> "The world needs a better spreadsheet"

I read this when I was a teen (as that's long ago). It was at a time Lotus was going to launch Improv in 1993! Improv was the attempt made by a very smart team at Lotus to reconquer the crowd that went to Excel.

But as you can guess, the great product never found its market (or never grew beyond a niche) and was killed a few years later.

cf. [https://en.wikipedia.org/wiki/Lotus_Improv](https://en.wikipedia.org/wiki/Lotus_Improv)

<comment><USER16> It's worth noting that Quantrix Modeler [1] (founded in 2002) did carry on the torch after Lotus Improv, and continues to exist. That said, it's not clear how much traction Quantrix got either. It was bought out in 2010 by IDBS and te deal value wasn't disclosed, but it was reported that they had only nine employees at the time of acquisition. Another very interesting earlier attempt in this market was Javelin [2].

[1] [https://www.quantrix.com/](https://www.quantrix.com/) [2] [https://en.wikipedia.org/wiki/Javelin_Software](https://en.wikipedia.org/wiki/Javelin_Software)

</comment></comment><comment><USER17> While I'm not entirely sure if "the world needs a better spreadsheet" is a stand in for "accessible prototyping tools" it's worth noting that things like Quantrix Modeler and DADiSP are the better spreadsheets it's just that no one uses them because Excel (and by extension Excel work-alikes) have path dependency on their side.

<comment><USER18> And those products are thousands of dollars a year while Excel comes bundled with every mass market computer.

<comment><USER17> Yeah, fair enough, that too.

I happen to think "paying for good tools" is a good thing but as a student/stockboy: A thousand dollars is a fucking lot of dollars, especially if your business is still running on debt.

</comment></comment></comment><comment><USER19> Fundamentally software development is about writing and managing complex systems. Excel and the like have limited capability to manage complexity and any simple system built with excel eventually turns to bad smelling unmaintainable chaos. So then people build tools that manage complexity better but are still "easy to use". And then those tools become so complex that software developers are the only people who understand how to use them. And then what's the difference between said tool and writing real code? After 10-20 years we are back to where we started. I wonder exactly how many times I will see this in my career?

</comment><comment><USER20> Not really. Most spreadsheets(~88%) have errors.

"Sorry, Your Spreadsheet Has Errors (Almost 90% Do)"

[https://www.salesforce.com/blog/2014/09/how-to-reduce- spread...](https://www.salesforce.com/blog/2014/09/how-to-reduce-spreadsheet- errors.html)

The 2008 source article is

"What We Know About Spreadsheet Errors"

[http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm](http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm)

<comment><USER21> If you read the blog, you'd see that the system he's suggesting is somewhat more robust than a spreadsheet. His example at the end is the Google Forms builder, which at least does a modicum of input validation, unlike your typical direct-entry spreadsheet.

And the point is not to completely dismiss the idea with a glib soundbite like that, but to actually take seriously building tools _like_ spreadsheets that allow non-technical users to build data-driven systems.

</comment></comment><comment><USER22> It exists already. It's called MS Access.

<comment><USER6> Except Access has many of the same issues as Excel. You can work around some of the nastier stuff like file locking by using liked database files and having everyone save their own copy of the "frontend" database file, but it's more of a pain in the ass than it's worth (and oh god is it slooow).

</comment></comment><comment><USER23> I agree, I automate generation of hundreds of spreadsheets a day.

I would like to see more scripting/automation features on email.

<comment><AUTHOR> OP. I was actually thinking something similar. Do you mean the ability to send out emails with app data rather than code and orchestrate them yourself?

<comment><USER23> I was thinking more on the processing of incoming emails, ones with attachments or routing. I worked years ago on an enterprise product that did this, but it was integrated with large printer.

<comment><USER24> What data was being sent back and forth? Why did you need to process the attachments?

</comment></comment></comment></comment><comment><USER25> Quip (a better spreadsheet) or Django web framework (its ORM and built-in admin can do wonders) are worth mentioning. Another example that comes to mind is how Vox uses Google Sheets for content & config: [https://product.voxmedia.com/2014/7/29/5863004/take-a- peek-a...](https://product.voxmedia.com/2014/7/29/5863004/take-a-peek-at-the- code-that-powered-the-verge-50)

</comment><comment><USER26> I built an app in Excel 5 years ago. It was a heat map for events, for stadiums, theaters, etc. I would build the static CSS/HTML and write out the files from Excel. It is still in use today. After having stopped working on it for a couple of years a minor bug was brought up to me recently. Luckily I had a windows computer again with Excel installed. Excel is a great platform for building prototype apps, or even long lived apps - especially 10 years ago. It is amazing the power that Excel has. But, a proper app should be built in JavaScript with a solid back end (F# being my fave). Although developing in Excel was a bit clunky it was amazingly easy to get beautiful customer interfaces and beautiful forms.

</comment><comment><USER27> Being part of design meetings, it's amazing how many endless customizations and workflow adjustments people like project managers and consultants like to request for a new piece of software. But when it comes down to it, most users don't want a complex, hard to understand interface that has so many features it's supposed to improve everyone's productivity. Most people want to use their spreadsheet, their Outlook calendar and their IE browser. Not because it's best at the task, but because that's what they know and are used to.

<comment><USER28> Of course users don't want anything complex, and if the resulting custom software makes a task more confusing and error-prone than a spreadsheet, the developers and designers have failed.

Instead, I read this comment as meaning a few different things:

1\. It is difficult to get users to try something different.

2\. Most users don't comprehend the limitations of the software with which they are already familiar.

</comment></comment><comment><USER29> Once you get all the security, backups, data validation and whatever exporting/search capability the people need a system like this is never simple. I wonder how happy they really were with his software vs relieved to have a semi-functioning system.

It still seems like something like this is in the realm of possible. Salesforce mostly does this, but its UI is garbage and most people end up hiring implementors for it.

</comment><comment><USER30> Quickbase does an amazing job with allowing non-tech users to create their own crud apps, and the model is very spreadsheet like, including grid edit if you want.

The trouble is the pricing model. $25/user per month for the edition that's not hobbled. For some use cases, that makes sense. For others, it's just way too high.

</comment><comment><USER31> Airtable is a better spreadsheet imho.

<comment><USER32> +1 on Airtable, it's the only app I have used in the past 5 years that fits great into workflows and allows me to peer into and sort the data based on the task / view I need.

</comment></comment><comment><USER33> What's with that garbage at the bottom right? I'm trying to read your article. Why would I want to talk to you before reading your article? Made me stop reading.

</comment><comment><USER34> Charged a close friend $3,000 for a few days worth of work?

<comment> crooked-v $100 x 8 x 3 = $2400, and that's for just 8 hours a day with a pretty gentle contracting rate.

<comment><USER34> $100 per hour for a Rails crud app?

For a close friend?

</comment></comment></comment><comment><USER35> how do people get a "hey HN" welcome line up on their site so quickly? This was posted here less than 2 hours ago. Do people really monitor incoming referrals hourly?

<comment><USER36> I mean...yes? Back when I had a dedicated office, there was a screen that was tail -f on various logfiles watching website traffic.

My sites were all personal projects, so the traffic was low enough that I could notice an uptick in traffic visually.

Also things like google analytics etc.

</comment></comment><comment><USER37> I swear to god, anytime anything pops up on a website when I click on it, it seriously pisses me off.

A fucking chatbox? I already hate your company.

A fucking chatbox from the author of a blog? I hate you and everything you stand for. You are what's wrong with the internet. You should know better, and you do. But you do this anyway. Just stop.

<comment><AUTHOR> OP. Yea, that was interesting on my end using chat. I probably would hate that on your end as much you did. I did have some pretty fun conversations though. I removed it, because that got exhausting.

<comment><USER38> I, for one, really liked it. And thanks for the chat, Matt!</comment></comment></comment>


Can preorders work for software-as-a-service companies? - <AUTHOR> http://nathanbarry.com/saas-preorders/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+NathanBarry+%28Nathan+Barry%29&utm_content=Google+Feedfetcher

<comment><USER4> You know that when folks like game companies sell preorders they're not actually taking and spending your money, right? Usually it's a token amount like $5 that just serves to make the customer invested in the product to make them much more likely to come back and purchase it when it's ready. They'll also happily refund your $5 or whatever if you change your mind or the product is late, etc.

Dinging a bunch of credit cards for full value and then spending that money to develop what you've already sold could easily turn ugly. I can't tell exactly what your product is, but assuming there is actual code behind it - <USER2> is hard and frequently takes a lot more work than you expect.

I'm not saying it won't turn out fine - but if you're simply looking to validate your product then i think it'd be really wise to keep 100% of that pre-order money segregated, unspent and available for no questions asked refunds.

<comment><USER5> Agreed. And no questions asked refunds are definitely available. I've written two successful book so the money itself isn't the issue. I just happen to have set a $5k limit on what I can spend personally.

If everything totally fails (possible, but not likely) I will repay everyone out of my own pocket.

<comment><USER4> I think that's great then and am super excited to hear how it turns out. The kickstarter-eque up front market validation strategies fascinate me - <USER3> the right set of circumstances I could see it becoming almost a revolutionary step in capitalism.

</comment></comment></comment><comment><USER6> Have you experimented with any sort of feature-request pre-order tier where the entities that pre-order early have direct say in what gets built? I know that you're obviously building for them, but is there any way to stroke their ego and make that part of the package?

<comment><USER5> That's an interesting idea. I haven't done it. I need feedback from customers to find out exactly what to build, but I would never want to be put in a position where I must build something a customer tells me to do.

That gets much closer to consulting or contract work. Not products.

</comment></comment><comment><USER5> As always, happy to answer any questions!</comment>


A rare peek at Homeland Security's files on travelers - <AUTHOR> http://current.newsweek.com/budgettravel/2008/12/whats_in_your_government_trave.html <comment><USER2> Since the Freedom of Information Act has to "to disclose records requested in writing by any person" [1], this is not a 'rare peek', it can be done by anyone, at anytime anywhere in the world since 1999. People have just been lazy.

[1]<http://www.usdoj.gov/oip/>

<comment><USER3> Even foreigners?</comment></comment>


Ask HN: Can 32-bit Interact with 64-bit? - <AUTHOR> I was reading up on malware and malware removal, I don't quite understand this though: Can 32-bit malware(Written in VB6) infect 64-bit systems in the way of adding code to the end of the programs memory space, access the kernal or inject code in an application? <comment><USER2> [https://www.corsix.org/content/dll-injection-and- wow64](https://www.corsix.org/content/dll-injection-and-wow64) ... "The solution I've settled on is to create a 3rd process, which I call the proxy process. The proxy process is an x64 process which is connected to the x86 process via stdin/stdout pipes, and whose job is to call CreateRemoteThread."</comment>


SIGGRAPH 2019: Path Tracing in Production 2019 - <AUTHOR> https://jo.dreggn.org/path-tracing-in-production/2019/index.html <comment><AUTHOR> SIGGRAPH is the ACM's special interest group on computer graphics, held annually. This SIGGRAPH course talks about how path-tracing / raytracing is used in production movies, including examples from some pretty big blockbusters (Avengers Infinity War, Endgame, Capt. Marvel, Spiderman: Homecoming, Alita: Battle Angel...)</comment>


10,000 People Sign Petition to Honor Alan Turing by Putting Him on the £10 Note - <AUTHOR> http://www.theatlantic.com/technology/archive/2012/03/10-000-people-sign-petition-to-honor-alan-turing-by-putting-him-on-the-10-note/254988/

<comment><USER2> Not sure I value the positioning of ones face on currency as many do. But I do love the man and while I'm here I'll leave this peculiar bit of foresight from him which reminds me of Siri:

 _"One day ladies will take their computers for walks in the park and tell each other, "My little computer said such a funny thing this morning."_

</comment><comment><USER3> The petition, for any UK readers who might wish to sign it. <http://epetitions.direct.gov.uk/petitions/31659>

<comment><USER4> A cultural note: Most online petitions are worthless useless spammy nonsense.

UK epetitions are different, because with enough signatures (currently 100,000) the topic becomes eligible for debate in parliament.

<comment><USER5> All you really get with a UK e-petition after 100,000 votes is it being sent to some low-end bureaucrat who may (or may not) forward it to the 'Backbench Business Committee'.

<comment><USER6> There have only been a couple of issues that have been taken seriously in parliament through e-petitions.

First was the details of the Hillsborough disaster and second was taking away state benefits from those convicted during the London riots.

</comment></comment></comment></comment><comment><USER7> Britain can never do enough to make right the wrongs it inflicted on Alan Turing, but it should never stop trying.

</comment><comment><USER8> There are priceless things, but for the rest, money represent the ability of humanity to communicate and exchange economic value so I often think about them as a symbol of what we've managed to achieve since the ancient times. And just like we evolved to exchange promissory value on a piece of paper, humanity made huge progress in self-governance and mutual respect. From the dawn ages of absolute kingdoms we've evolved to constitutional monarchies and democratic republics. We've abolished slavery, enabled universal voting in most parts of the world and probably in some decades almost everyone will have the right to marry the person they love.

Alan Turing was among the most brilliant persons of his time, yet in his society he ended up injected with estrogen, which left him impotent (he also developed breasts and one year after this therapy he used cyanide to kill himself - <http://en.wikipedia.org/wiki/Alan_Turing> ). If you're in UK, please sign this petition. It would be a huge honor to have on the very symbol of economic exchange Alan's face - a memory of our wrong-doings and of the progress that we made until now and the one that is yet to come.

</comment><comment><USER9> It is progressive to have a gay computer scientist and mathematician on a note. A lot of current British national identity and history is built around WW2, so "fought the Nazis" will also help the chances.

</comment><comment><USER10> I've always been quite proud of having Darwin there, perhaps a commemorative note?

<comment><USER11> I just think Turing is a great choice to troll the religious conservatives - replacing a creationist with a homosexual.

<comment><USER12> You can be religious and still accept homosexuality. It's a shame it even gets brought up. Let us remember Turing for being a great Mathematician.

<comment><USER13> I think his homosexuality mainly gets brought up because of the manner of his death.

For instance, John Nash was apparently stripped of his security clearances due to being caught soliciting men in toilets, which wasn't even alluded to in the Hollywood version, but given that he wasn't then arrested and driven to suicide and furthermore is still alive and re-married (so we have to be 'sensitive' about him), this is not overly dwelt on by those who seek to tell his story.

</comment></comment></comment></comment><comment><USER14> I wish Tommy Flowers contribution got more recognition too - maybe they could put him on a fiver?

</comment><comment><USER15> I like having Darwin on the £10, but I'd like to have Turing on a note as well. Maybe the £5 would be better, though that would mean getting rid of Elizabeth Fry, who I believe is the only woman currently on the currency (except Her Majesty of course), which may upset some people. The other options are the 20 and 50, which have Adam Smith and Boulton and Watt, respectively.

<comment><USER16> They are "retiring" Darwin and will be replacing him with someone else anyway. May as well make it Alan Turing.

</comment></comment><comment><USER17> Let's start similar petition for Donald Knuth in the US.

<comment><USER18> I realize you were trying to be cute but comparing the two individuals in this context is tacky and makes light of the terrible manner in which Turing was treated. Until our society advances more I think it is best to avoid using homophobia as the basis of a witty remark...

<comment><USER16> The context of this is "put a famous mathematician on the £10" so it hardly makes light of anything.

<comment><USER18> So the impetus behind this is purely to recognize Turing's contribution to math?

<comment><USER16> Obviously not, it's near impossible to get into a discussion about Alan Turing without bringing up the way he was treated. However British money already features scientists (Turing, if selected, will replace Darwin) and this has far more to do with recognizing Turing's accomplishments than his treatment.

There are many people who think that it's a good idea to feature scientists on money and making that suggestion for US money isn't in anyway taking Turing's treatment lightly.

<comment><USER18> You honestly think that months after the pardon refusal this has more to do with recognizing his math/sci accomplishments than his treatment? Is the atlantic in the minority for mentioning "moral turpitude" before enigma?

If that's the case it seems like waiting a little while and letting the pardon refusal fade from recent memory would be a more effective advocacy tactic.

<comment><USER16> Yes absolutely. If he made no discoveries at all we wouldn't even know who he was.

Do you honestly believe that using this discussion as a starting point for a general discussion on having scientists on money is insensitive?</comment></comment></comment></comment></comment></comment></comment>


No more CSS and HTML, just JS - <AUTHOR> http://ojjs.org/ <comment><USER2> This post is getting a lot of flack from people who haven't given it more than a glance.

\</comment><comment>-Benefits

1\. SEO is not a problem.

Since OJ can be compiled on the server-side, it's comparable to EjS, JADE or other templating languages, which means SEO is not a problem.

2\. Current code-size can be ignored in the long run.

This code doesn't have to be sent to the client (since it can run on the server), could possibly be hosted by a CDN and cached across the web, and can probably be tightened up in the future.

3\. CSS is still available, but the views know about their css files and are coupled with them

4\. True MVC on the front end

OJ gives us the chance to do true MVC in the web frontend, without having a javascript view and an dom view and css styles that are separate, but that work together to make one thing. It seems to me that they're really made for each other - shouldn't they be together at last?

5\. Sharing code will be easier

OJ could eventually be supported by a package manager that allows you to include (or install for server-side) js objects for things like youtube videos, but also for tweets etc. Separation of concerns (So your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html & js etc) will also reduce complexity in larger apps.

\</comment><comment>Trade offs

1\. Yet another framework to learn/use

2\. May be slower than what you currently do to render pages

3\. If used client side, you may weaken your site's SEO

4\. New engineers to your team will likely need to be brought up to speed.

5\. (short term) There are likely weird bugs you'll pull your hair out over.

<comment><USER3> Just to add to #5: OJ already is using Node's npm as a package manager. It was my thought that server-side templating aligns perfectly with node, so all plugins are already just a require away (packages are named: oj-youtube-video, oj-markdown, oj-twitter-button, etc).

In addition oj has an (optional) server side commandline tool that already supports a Browserify-like approach of building websites that can use Node packages. So if you are looking to make a static page for say GitHub pages, the OJ commandline tool already supports using npm as an OJ package manager.

One last thing: my top priority right now is Express Server integration to finish out the dream of shared Client and Server code in node. This will allow use of npm as packages even more, so if any experts on Express are out there, I'd love to talk to you.

<comment><USER4> I think this is fascinating -- but I'm not quite sold yet.

I've been thinking a lot about frameworks along these lines; use js (or something that compiles to js) for the logic, allowing shared code-bases on server and client. One major motivation would be to seamlessly render on server for clients that doesn't support javascript (be they lynx/w3m or some crawler etc). Another would of course be to try and keep things reusable.

I'm not so sure html+css+"interactive/event-handling"-js is a good "compile target", though. I'd much rather see something as close to the output as reasonable -- because there are so many corner-cases with html and css. This is one of the reasons why I like the idea of zope's TAL/METAL templating[M] so much. My interest in TAL is also why I don't think this (general architecture) is going to quite work.

With TAL, you can basically make a mockup that _is_ a template, complete with sample data. But then you need to break up that template to have widgets. And widgets need to be inserted across different areas of the document (think a calendar, where you mouse over events to change an info box. That can be structured, but it is going to cut across a lot of you entire page/app. Even if you don't load content asynchronously). This is done in Plone/Zope using METAL (Macro Expansion for Template Attribute Language).

In fact, the Plone project has essentially given up the idea of using TAL+METAL to theme a site -- it is now (ME)TAL->html+css+js -> page/app "base". Then that base is modified/rewrtitten using diazo[D] (xml transform but with easy support for using css selectors rather than forcing full xpath syntax on a poor dev) - that basically can include new css and js -- but fundamentally can rewrite the entire html-document, splicing in content in sections.

I'm not sure that _that_ is the best way forward either -- but I think that is one of the best ways of writing rich html "documents" \-- or systems that revolve around pages. For "pure" apps, I think maybe a full on js approach like ELM[E] is better -- the code is cleaner -- you don't really care about the html, css or even javascript as such -- you focus on the functionality.

As for Ojs, I looked a bit at the examples:

      http://ojjs.org/download.html#examples

and one thing struck me -- is there really a reason for the js client and server examples to be different? Couldn't/shouldn't the server side tools be able to deal with the code for client side -- so that you can write once, and then deliver server side or client side from the (exact) same code base?

Despite all this, I think it is an interesting project.

[M] [http://en.wikipedia.org/wiki/Template_Attribute_Language](http://en.wikipedia.org/wiki/Template_Attribute_Language) [E] [http://elm-lang.org/](http://elm-lang.org/) [D] [http://docs.diazo.org/en/latest/index.html](http://docs.diazo.org/en/latest/index.html)

<comment><USER3> This is really insightful. Thank you for giving it serious thought=). The main reason to make them different is I saw them as different use cases: the client-side folks just want a single script (oj.js) include to make things easy to get started with. The server-side people are already comfortable with the Node npm module system and so using `require` to include different files / modules made sense. I mostly didn't want to force everyone to use a command- line tool / Node just to use OJ.

That said, I completely agree and hope over time more and more people will embrace the server-side way as it makes downloading and updating plugins really simple. Maybe in time that path should be emphasized more.

<comment><USER4> Perhaps adding support for thin "client-side" shim, so that you'll have just a html of something along the lines of:

            <title>OJ Example: html shim</title>

Something went wrong

So sorry. The server was unable to detect that
              your client doesn't support javascript. Please try:
              magick.
              (Maybe that should be a client side redirect, via a meta-tag:)
              <meta http-equiv="refresh"
                 content="1; url=?force-server-side-rendering=true">

Now, example.oj will pull in stuff via require etc, and given a "smart" server, the same page/app can render client side and server side?

[edit: The oj.js script should also probably be able to redirect the client "back" to client side rendering, if it detects js -- so that if google links to url/?server-side-rendring=true -- not all clients from google will be "forced" to do server side rendering.]

</comment></comment></comment></comment></comment><comment><USER5> Well, it's only 11 000 lines of js... Plus Backbone, plus jQuery, plus underscore, plus ace. Loading the source page takes about 15s on my computer... I'm not sure I would like my index.html to like this [https://github.com/ojjs/ojjs.github.com/blob/master/index.ht...](https://github.com/ojjs/ojjs.github.com/blob/master/index.html)

<comment><USER6> Yes, it seems like added complexity and reduced performance for uncertain benefit.

The whole point of HTML and CSS is to be declarative, non-procedural ways of specifying presentation and UX behavior. The rationale is that designers writing CSS rules is safer than developers writing Javascript code -- for those cases where the desired result can be achieved with either approach.

So why turn back the clock and go back to messing with code and debugging it? Unless I am missing something, heavy-weight pages with potential for bugs does not seem like a win.

<comment><USER7> HTML is a language for describing documents, right? The way I see it, there is an issue with HTML today. These days, many web developers are now exploring alternatives to a documents-based paradigm, and gearing their apps toward being "long-lived", while retaining the URLs and graphical support that modern browsers give us. Ember is a great example of this, there's very little markup you actually have to write when using Ember views and components. I don't really build "web sites" anymore, I build "web applications" which are typically one page but include all of the application's contents within that page. They do act the same, but are coded in wildly different ways.

Don't get me wrong, I like HTML and I'm not trying to disrespect what was arguably the first foray I had with "programming". But if we are intending to make the web into something more along the lines of a massively distributed application runtime, rather than a repository of documents that anyone can access, where does a document markup description language fit into all that? When developing some (kinds of) applications, I feel that HTML only serves as an obstacle, rather than a means of helping me make the app. I feel like I do most of my "real work" in CSS and JavaScript.

<comment><USER8> Why can't it be both?

Applications are still, in essence, a type of interactive view hierarchy of document. The web can serve up both types of data: document-based (e.g. Wikipedia) and application-based (e.g. Gmail). Being able to have a core toolchain of three inter-related languages that can communicate with each other that you can use as required should be the final goal. For instance, if you're writing a web application, you could only use CSS/JS, and if you needed to write a very simple blog, you could use all three, or just HTML and CSS.

Having more options never hurt anyone. Better JIT of JavaScript code would break pure JS open, allowing full apps to be written without language fragmentation. Those who will still require stylesheets can use them as they wish. It's a win-win situation on both ends.

<comment><USER9> > he web can serve up both types of data: document-based (e.g. Wikipedia) and > application-based (e.g. Gmail).

an email message is a document too.

<comment><USER10> > an email message is a document too.

An email _client_ is not.

</comment></comment></comment></comment></comment></comment><comment><USER11> What problem is ojjs solving and what are the trade-offs?

For me personally, the design principle of "separation of concerns" has always worked well, especially in a team environment. Having a pure designer (on photoshop or illustrator), then an html/css expert for coding pages and finally a programmer for adding dynamic content works out as a nice pipeline for web development. With ojjs, the programmer and html/css person would have blurred lines separating their responsibilities. It is a cool project, but it seems like a step backwards to me. Maybe it's just a step sideways or a better way of doing things for a team consisting entirely of programmers.

[https://en.wikipedia.org/wiki/Separation_of_concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)

<comment><USER12> That level of separation exists in dream worlds. Have you ever seen a job application for an "HTML/CSS Expert"...

<comment><USER13> This isn't as uncommon as you might think.

</comment></comment></comment><comment><USER14> Not really sure what problem this is trying to solve. I am more enthused about the potential of Web Components, shadow-dom etc. [1] Take a look at Polymer [2]. By abstracting away the concept of the contrived set of HTML Elements we currently have we can create new 'complex' elements/components while retaining consistency with the rest of the DOM API.

[1]: [http://www.w3.org/TR/2013/WD-components- intro-20130606/](http://www.w3.org/TR/2013/WD-components-intro-20130606/) [2]: [http://www.polymer-project.org/](http://www.polymer-project.org/)

<comment><USER15> There is also x-tags [1] by Mozilla which uses some polyfills from polymer.

They also have some repositories for ready to use webcomponents like x-registry [2] or brick [3].

[1]: [http://www.x-tags.org/](http://www.x-tags.org/) [2]: [http://registry.x-tags.org/](http://registry.x-tags.org/) [3]: [http://mozilla.github.io/brick/](http://mozilla.github.io/brick/)

</comment></comment><comment><USER16> _HTML Version - 56 Characters, no dependencies:_

They

create

themselves

 _OJJS Version - 57 Characters, thousands of lines of js dependencies:_

var myList = oj.BulletList('They','create','themselves');

The fact that just writing the html output is the same (and in this case less) amount of characters then the ojjs functions makes me unsure about this. especially considering all the extra dependencies.

<comment><USER17> I would also argue that in terms of maintenance, it would be more time consuming for me to debug native html, css, and javascript, and then fix those bug in a completely different environment.

<comment><USER16> Absolutely. I agree. And there are lots of other points worth arguing too.

My point in bringing up something like the difference in character count (not counting characters in the dependencies) is that just calling the function is already more work than basic html. That immediately is a NO for me.

One could argue maintenance, incompatibilities, bloat, optimization, debugging, and so much more.

<comment><USER18> > My point in bringing up something like the difference in character count > (not counting characters in the dependencies) is that just calling the > function is already more work than basic html.

To nitpick, to get your HTML, the OJ example could actually be:

> BulletList('They','create','themselves')

So no, it's not more work (41 characters).

</comment></comment></comment></comment><comment><USER19> The big issue I have with this approach is that you'll eventually need to do one of the following: hire a designer that can javascript (rare); hire a javascripter that can design (rare); sit and tediously convert your designer's static html and css line-by-line into javascript templates.

It's not impossible to be an expert graphic designer _and_ web developer, but they are both extremely deep disciplines and people with the dedication, inclination, and aptitude for both are few and far between. Unicorns, etc...

This is fine for one-offs and side projects, but trying to build large project around this seems like an unnecessary extra layer of complexity (not that the current standard isn't complex, it's just relatively entrenched, for better or worse :)

<comment><USER20> My thoughts exactly, word for word. If you have ever built a UI heavy app, you would know how important it is to have the separation between html, css and js. It's not just about putting them in different files, it's about the context. It's separation of duties.

</comment></comment><comment><USER21> Please do not use something like this if you're building your next project. _NOTHING_ is wrong with using mustache or so for templating, but this is just plain wrong.

You will know how much it costs to use something like this if you have a project that you've worked on for weeks or months and need to hand it over to another developer. Or actually any other interaction with a third party like a designer or frontender that's used to just juggling around some tags for preference or layout optimisation.

<comment><USER2> Sorry, but there will always be new tools and newer, better ways of doing things: best-practices will aways change, and people will always need to be re-educated. This is even more true in this industry than anywhere else, and I've noticed that the rate of this change has been dramatically increasing (which is why there's such framework fatigue in this thread).

Do you have any other reason why we shouldn't use OJ?

<comment><USER20> I am sorry, you make a good point, but it's for "better way of doing things". Such comment is so far deep into the common sense territory that there is hardly any reason to mention it explicitly. This discussion is happening with exactly that in mind.

Other folks here have mention the separation of concerns. Is there something that you can say related to that? Loved your summary of benefits and trade- offs, but can you please address MarkHarmon's comments? Thanks.

<comment><USER2> Separation of concerns is increased with OJ: Your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html(template) & js. This will significantly reduce complexity in larger apps.

<comment><USER20> How is that different than another framework such as Angular JS, or something like web components perhaps? Each view, or directory or component can have it's own CSS file with existing solutions too.

What we are seeing here is an attempt to solve the same problem, but by doing all the work by using JavaScript. Cool. But not impressed.

<comment><USER2> Currently, views are split into 3 places: html, css + js (for rendering updates - usually done with a template). The big difference here is saying that the view is actually all three things/ that it's made up of all three components, which is closer to the truth than other systems of thinking.

Can HTML be the view without css and without js binding for events and updates? Not in a modern app!

Can CSS be the view without HTML/JS? NO!

Can JS alone be the view? Yes, but you'd have a lot of inline css and html - it'd be and a pain in the ass to maintain.

So if you want a single, true View in your MVC, you'd need a view that has all three parts. Other frameworks like backbone try to do something similar - backbone allows you to let your view have a template, but backbone views rely on external css and often attach to dom elements that aren't even in the view's template. So what you have is a view that's only referring to/aware of a few of it's actual dependencies. That seems sloppy if you ask me.

Also, if I had a TweetView that was a backbone view, and I wanted to move it to another person's system - maybe I created an awesome design and called it AwesomeTweet - other people who wanted to consume AwesomeTweet without OJ today would have to include a css file, some html (or a template) and some JS. Each presents a rich opportunity for namespace collisions, and for my bad documentation to make it difficult to import AwesomeTweet as a module. Instead, OJ could allow a simple line like showAwesomeTweet('2131221121'), which would be guaranteed to work everywhere, simply.

Does this explain the "why" better?

<comment><USER22> "Instead, OJ could allow a simple line like showAwesomeTweet('2131221121'), which would be guaranteed to work everywhere, simply."

Ah, but you are sacrificing uniformity of design there. What if I would like the style of the tweet to be consistent with the overall style of my app? And this style is managed by a separate designer not a programmer?

Modularity works fine for behaviour, because it is better to abstract and encapsulate behaviour. But modularity doesn't necessarily work great for looks and feels.

<comment><USER3> OJ actually supports the ability to Theme objects which makes it much simpler to create design abstractions like you're talking about. It was inspired by the Bootstrap approach for customizing the look of different elements. The basic notion is OJ creates a CSS class that you can add and remove from an object to change its look. This can be done in a separate file (or even plugin) for designers to configure separately.

Here is a JSFiddle I made to demonstrate. This isn't even in the docs yet, so I made this just for you=).

[http://jsfiddle.net/evanmoran/RmM96/](http://jsfiddle.net/evanmoran/RmM96/)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> This would be terrible from a performance perspective on mobile. Not because the phone executes JS slowly (it might, but that's not issue). The problem is the network latency around downloading the initial html (whatever little html you need) and then sending a further request to download the JS.

Pagespeed goes into this a bit here: [https://developers.google.com/speed/docs/insights/Prioritize...](https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent)

</comment><comment><USER24> Why do people keep trying to abstract away the parts of web applications that have been carefully designed to solve that particular part of the problem as best they can with a 'one size fits all' solution?

To me the answer is obvious: we have people who don't understand CSS, who don't understand HTML, who _do_ understand JavaScript (or Java, or Ruby, or Go, or whatever) who _want to make web applications_ but have no interest in learning or understanding the reasons why we do things a certain way.

Frankly it depresses the hell out of me for the next generation of web applications, because it feels like we're taking a technological leap backwards.

</comment><comment><USER25> Similar to something like ExtJS. Using Ext you declare the UI purely with JavaScript (CSS and HTML can be inserted if desired but that is antithetical to the standard practices).

It works pretty well. But when you have complex layouts, your JavaScript files can become very complex with many layers of nested object definitions. I use Ext and love it, but personally I think an HTML markup approach to defining UI's is cleaner.

</comment><comment><USER26> Love the concept, but the site itself (which I assume was built using the framework) is visibly laggy (in Chrome, on a MacBook Pro) - I'd be worried about using this for anything where performance was important, and for mobile (esp Android), it would probably be too slow to use. :-(

<comment><USER3> The next two big pushes are performance and Express (server-side) support. From my own testing OJ compiling, rendering, and DOM manipulation are actually pretty fast. As for the perf issues I am seeing (especially on mobile) I think they are at least partially caused by creating 40+ AceEditors with syntax highlighting and dynamically loading iframes like YouTube videos and TwitterButtons.

That said, lay all the perf blame on me! I can promise it will get better -- though in my defense this is the first release after all. Literally no one had heard of OJ until yesterday=).

</comment></comment><comment><USER27> Uhhh...shouldn't the site itself be built using the framework it advertises? Because the page structure and styling is all there even with JS turned off.

<comment><USER3> The site definitely was written entirely in OJ=). What you are seeing is that OJ, since it is just JS, can be run server side as well as client side. Server side it generates HTML/CSS (so it renders with JS turned off), but client side it renders directly to the DOM for faster templating, and automatic event binding.

The tool for server side static site generation is available in node npm. You can install it with `npm install -g oj`. Example projects can be found here: [https://github.com/ojjs/oj-examples](https://github.com/ojjs/oj-examples)

<comment><USER28> This server side execution is a good idea ! I think this is an important/valuable point of your idea.

</comment></comment></comment><comment><USER29> All benefits to having a CSS file are completely lost using this method, in addition to the aforementioned performance hits. Could be cool for creating widgets and forms on the fly, but would definitely not recommend creating an entire site, let alone a webapp of any size or scale, using this tool.

</comment><comment><USER30> Umm ... why?

(sorry, that's the most constructive I can get with this)

<comment><USER31> Because you can.

Pretty much everyone's had the idea that, since HTML is a structured markup language, you can "simply" represent it in whatever language you're working in. It's great when you're a noob & want to make something ideologically pure.

It just turns into a giant pile of unmanagable shit if you try to extend it out to anything remotely resembling a real world application. Even a simple layout like HN would require an incomprehensible mess of nested objects/s-expressions/functions if you chose to abstract the raw HTML away. This is why everyone that actually develops web applications resorts to templates.

</comment></comment><comment><USER32> Seems similar to Reactive Coffee: [http://yang.github.io/reactive- coffee/](http://yang.github.io/reactive-coffee/)

Having proper components is a big win. However, it seems it requires a command line dependency to the build app, which would be nice not to: [http://ojjs.org/docs.html#file-types](http://ojjs.org/docs.html#file-types)

<comment><USER3> Author here -- Just to clarify OJ is a javascript library (oj.js) with only one dependency jQuery. It doesn't need specific file types to work and the files types in the docs are just talking about the (optional) command-line tool -- basically a static site generator to make simple sites (github pages) easier to make.

Check out this JSFiddle to see how the dependences work: [http://jsfiddle.net/evanmoran/c3Reb/](http://jsfiddle.net/evanmoran/c3Reb/)

(Notice that OJ doesn't need HTML or CSS!)

</comment></comment><comment><USER33> A language like Elm seems more innovative and interesting: [http://elm- lang.org/](http://elm-lang.org/)

It removes HTML, CSS and JS from the equation with just one language, Elm, which uses FRP (functional reactive programming) for doing UIs.

</comment><comment><USER34> Stuff like this is useful to an extent but not when you go so low level as to generating individual divs, ol and spans like this.

For example, it makes sense to have a Javascript class such as "ShoppingListView" that takes care of rendering a shopping list via a template that it references. A component like a shopping list is coarse grained enough to be styled and designed on its own (by designers) and then stuck into a template (by designers) that the Javascript developer can then use and populate in code.

oj just takes us back to the tedious GUI development of Swing style frameworks. It is unfortunate that some people in every generation forget what the previous generation has already learned.

<comment><USER3> This is actually exactly what OJ is trying to solve: creating your own helpful objects to make reasoning about your site. The plugin objects are just a bonus!

So ShoppingListView would be a powerful object that you could test and reuse. For example in the ojjs.org site I have an object called TryEditor, which does the live compiling examples. Clearly this isn't a plugin people will want (though it is made with the AceEditor plugin, which is pretty darn useful!), but it helped me to abstract it easily so I could use it, well, pretty much everywhere=).

Another way to think of it is imagine you were making Gmail. It would be helpeful to have an object handle EmailView, LabelView, and FriendView. These things are tied to data but wouldn't it be easier to interface with them as an object interface (addEmail, archiveEmail), then with direct DOM manipulation?

<comment><USER34> Indeed, that is actually how my project (strut.io) does it.

IMO you'd get a better reaction if you put a large chunk of your Plugins page on your main page. The "plugins" page better illustrates the purpose and vision of OJJS. The example on the main page is so low level it turns people off.

That being said, I still think the bulk of the "markup" should be in markup and reside as a template for your "plugin" or component to use.

So you have an EmailView component but with an EmailView template file as well. The EmailView is instantiated and manipulated in Javascript but it still has the benefits of markup via its template file.

Concrete example: Template: [https://github.com/tantaman/Strut/blob/master/app/bundles/ap...](https://github.com/tantaman/Strut/blob/master/app/bundles/app/strut.storage/templates/StorageModal.bars) Component: [https://github.com/tantaman/Strut/blob/master/app/bundles/ap...](https://github.com/tantaman/Strut/blob/master/app/bundles/app/strut.storage/view/StorageModal.js)

<comment><USER3> Thanks for the suggestion about the plugins. I think you are right they aren't emphasized enough=).

As for separating templating from the View it is a good point. In OJ you can use functions to create templates (or partials) since everything is just code.

I did find the unification of structure (HTML) and code (JS event bindings) quite helpful because this way the code that needs to find the HTML to bind an event is the very same code that created it. This removes the need to have class names / ids just so you can refer across HTML/CSS/JS boundaries.

</comment></comment></comment></comment><comment><USER35> Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.

</comment><comment><USER36> This feels like it is trying to reinvent the wheel. Is there something wrong with using HTML and CSS?

<comment><USER37> "Is there something wrong with using HTML and CSS?" I think yes and there is room for improvement to both but I don't think this is the correct solution for the problems.

<comment><USER36> I agree with this. I didn't mean to make it sound as if HTML and CSS were perfect. There is always room for improvements. For example, with CSS you now have the option to use LessCSS or SASS.

</comment></comment></comment><comment><USER38> I think the "no more CSS and HTML" misled us all.

In other words, if you think of this as a way to generate HTML snippets with events binding, then, this might not looked as such crazy idea. Of curse when it aims at building the entire website with, one will wonder why.

Having said that, a suggestion to the author, start using name spaces, i.e. put all plugins under the namespace of .plugins, e.g. plugins.YouTube(), plugins.Ace() instead of just YouTube() and Ace().

</comment><comment><USER39> I absolutely love JavaScript and being able to use one language from database to server to client in my current stack BUT I am very skeptical about using JS for representation and styling. Maybe JS can be massaged into a great language for representation and presentation, but I would bet HTML and CSS are far better suited.

</comment><comment><USER40> Huge step in the wrong direction.

</comment><comment><USER41> I started working on something similar to this, and left it as another object to gather dust on my SSD after it proved like a very inelegant way of making web apps/sites. Dunno, might have just been doing it wrong, but OJ seems very similar. Blog post on it here: [http://www.spectrumcoding.com/projects/xalt/2013/06/27/xalt....](http://www.spectrumcoding.com/projects/xalt/2013/06/27/xalt.html) and repo here: [https://github.com/Mirceam94/xalt](https://github.com/Mirceam94/xalt)

</comment><comment><USER42> Good, so Swing fans can finally write webapps.

<comment><USER43> Exactly, Swing is a great framwork(It has it's own problems/limitations, every framwork has).

</comment></comment><comment><USER44> OK, I won't add another "Why?"...but I'll just say that this paradigm already evokes a stomach-turning reaction from some people...why do the colors have to be so off-putting? It's tolerable on a standard Mac screen, but on my (cheaper) Dell monitor...which, let's face it, a lot of monitors are uncalibrated, the colors are not comforting...

There's already a lot of work put into this, it's worth going that extra step and make things look less like the messy days of HTML and Java and Flash a decade ago.

</comment><comment><USER45> Reminds me of building views in Java...

</comment><comment><USER46> "To a man with a hammer every problem looks like a nail"

</comment><comment><USER47> "build websites with objects"

Why not start with some content instead?

</comment><comment><USER28> Why would you remove HTML, it's the easiest way to create a UI ? Also this introduce a lot of coupling between the style, the structure and the logic.

</comment><comment><USER48> Although I respect the effort put into making the API look neat and work properly, I don't think it's a good idea to use JS for yet another thing instead of using the right tools for the right job.

Check out this presentation by Nicholas C. Zakas: [https://www.youtube.com/watch?v=li4Y0E_x8zE](https://www.youtube.com/watch?v=li4Y0E_x8zE)

</comment><comment><USER49> This is horrible horrible things to do, a giant step...back. The entire separation of concern is destroyed this way by mashing up everything into object that is completely unnecessary. The entire internet is built around loosed couple system so it wont' fall apart when a ending body tag is missing. But with objects, that's not the case.

Please stop the madness.

</comment><comment><USER50> Very interesting. Its become dogma that the markup and event handlers should be separate (for example you never add an onclick html attribute to anything). There are many good reasons for this. But I suppose if you think of this kind of like t ejs templates or something, its not so bad. Seems like an interesting way forward.

</comment><comment><USER51> There's a javascript wrapper around all html and css functionality so instead of creating a .html file you create a .js file and have javascript functions like h1('HTML Creation') instead of html like
HTML Creation
. Is that right?

Interesting. But why would we use this? Or is it just for fun?

<comment><USER3> The real goal is create objects that act as reusable building blocks for the web. The tag functions like h1/div are just a stepping stone to get there. The real point is to help everyone make a YouTubeVideo or a TwitterButton with one line of code=).

Check out this JSFiddle to make Vimeo videos!

[http://jsfiddle.net/evanmoran/yPXuL/](http://jsfiddle.net/evanmoran/yPXuL/)

</comment></comment><comment><USER52> The more I read the comments trying to explain this library, the more it reminds me ASP.NET Web Forms, only in JS.

<comment><USER53> Well, to be fair, ASP.NET Web Forms still encourages you to use a lot of hand- coded HTML/declarative markup with code-behind files in C#/VB. However, from my experience writing custom web controls in ASP.NET, OJ is similar in concept to using things like System.Web.UI.HtmlControls or the HTMLTextWriterTags with HTMLTextWriter to generate HTML content in code. Or like ASP.NET MVC HtmlHelpers. Still, all those technologies were strictly meant to be server side - one place where things like OJ are useful (rather than typing in big strings of HTML!).

I've toyed with my own similar tech to OJ in Javascript before, but couldn't justify the overhead in the client at the time.

</comment></comment><comment><USER54> It seems like a clever way to avoid the decoupling of content, presentation, and behavior, each with their own focussed, domain-centered language offered by the traditional HTML/JS/CSS set up...

But I don't really see _why_ I'd want to do that.

</comment><comment><USER55> Great technology.

But it reminds me a little bit to perl cgi in the 90's.

        print h1('hello world');

I mean, this is great for people fast learning, but will never work against "fronted" people in the average (non top) company.

I wish I'm wrong.

<comment><USER33> Build good ideas, don't be constrained by limited people.

<comment><USER55> In any other random moment, that sentence could have sound simply inspiring to me.

But right now. At this point when I'm right now very long to explain, that sentence, has made my day. Up-voted.

</comment></comment></comment><comment><USER56> A couple other stabs at this problem:

uiji.js [http://aakilfernandes.com/uiji.html](http://aakilfernandes.com/uiji.html)

domo.js [http://domo-js.com/](http://domo-js.com/)

<comment><USER57> It reminds me of EnyoJS [http://enyojs.com](http://enyojs.com)

</comment></comment><comment><USER58> I like the idea even though I am not a JavaScript developer per se. The examples are fun to play around with. It hides so much on the backend that I definitely would be worried about performance. Fun stuff.

</comment><comment><USER59> I think the title presages the coming of the apocalypse. The two ok-ish parts of the web replaced by the horrible one that we are all stuck with. Next step, replace all three with 666 and call it quits.

<comment><USER3> This is my favorite comment by far. Dare I say this could be the the work of the Illuminati? =)

</comment></comment><comment><USER60> So it's like a WYSIWYG that you need to know JavaScript to use?

</comment><comment><USER61> Good idea, I am currently working on something very similar, but built on Scala/Scala.js. Javascript is just not the right language for this, just as Java (GWT) wasn't.

<comment><USER3> First off Scala is amazing -- I'm using it for API servers -- so I'm very curious how your framework turns out=).

As you might imagine I would disagree that JS is the wrong language simply because it _is_ the web. Clearly abstracting JS to other languages can be quite useful (CoffeeScript), but by making your building blocks in JS every developer, library, or framework can use them. They become universal. If OJ can add YouTubeVideos, anyone can. It would be harder to do this if it was written in another language.

<comment><USER61> I agree with you that JS has more wide-spread appeal. But it just is not the right tool for the job. Obviously, I have to be clear about the job. The job is writing a web application that lets gmail look like a school project.

<comment><USER62> but contrary to what people believe you dont create such apps with a big monolitic framework , but by using a lot of little modular libs. Gmail is build on google closure lib which is exactly that.

<comment><USER61> Well, Scala is more modular than google closure lib can ever hope to be. By the way, Scala.js builds on top of google closure.

</comment></comment></comment></comment></comment><comment><USER63> Bug report: When the page loads the caret is focused in the textarea but using the arrow keys moves the entire page and not the caret inside the text area.

</comment><comment><USER64> Seeing CSS before HTML freaks me out more than it should.

*HTML & CSS

<comment><AUTHOR> I suppose this post may benefit from the misspelled advert effect =)

</comment></comment><comment><USER65> So, how well does this framework handle screen readers, like JAWS? All javascript, all the time is terrible from an accessibility standpoint.

<comment><USER3> Since OJ can render server side it should come down to people as the HTML/CSS screen readers know and love. One way to think about OJ is as a fancy new Jade-like templating system. If screen readers work off of Jade (and I believe they do) then they should work off of OJ as well.

<comment><USER65> That I can understand. I think the biggest thing that was rather off-putting about this project is that it seems that you're selling it as throwing Javascript blobs to the client to render, instead of as a primarily server- side templating system, which makes a lot more sense. However, it does lead to a request to put in support for ARIA tagging ( [http://www.w3.org/WAI/intro/aria](http://www.w3.org/WAI/intro/aria) ), because if anything, baking accessibility support like this into a templating language makes it easier for people to reach disabled people who want to view sites.

I've got to apologize for the harsh tone of the original posting. I have a few friends who are either legally or totally blind, and have had to help them try to find software that is reader-compatible so they can interact with the world around them. So seeing the "everything is dynamic" ability sold as the big reason to use this templating language, and knowing that readers can get confused if there's a lot of weird actions going on with the DOM, made me frustrated that there was yet another tool made that will further alienate these people, and make it harder to use one of the most awesome tools made for communications. Too many people take a path that is essentially "fuck the blind", which is just saddenning.

</comment></comment></comment><comment><USER66> Maybe I am misunderstanding something, but it seems like all the HTML is created as a side-effect. How can this possibly be a good idea?

<comment><USER3> Thank you for reading the site so closely you actually noticed=). The side- effect notation I absolutely cringe inside for, and this (along with the jQuery dependency) probably took the most soul searching.

What it came down to is this behavior leads to a really nice syntax inspired by the excellent coffeekup js templating language ([http://coffeekup.org/](http://coffeekup.org/)). The key is you can't really do computation or logic in anything but a function so using functions for nesting elements leads to elegant code. For example you could generate `li` tags inside of a `ul` tag: ul(function(){for loop{ li(...)}}).

That said, you don't have to use the functional notation to use OJ. All the functions and plugins support an _ variant (_YouTubeVideo, _div) that don't emit, and in addition everything in OJ can be written with a list syntax I call OJML. The syntax looks a bit like lisp and is actually what the functions, plugins, and css are all generating: [div, {'class':'my- cls',[YouTubeVideo,'url/to/video']].

</comment></comment><comment><USER67> Ha ha. No designers. Remember Java applets? Yeah, that was a thing. The rest of us will keep doing HTML 5 and DOM. Bye.

</comment><comment><USER68> This is what you get for "open web" \- treating symptoms instead of the disease that is JS, HTML and CSS.

</comment><comment><USER69> Man ... Every day there is a new ".js" library coming up. How to even keep track of them? :O

</comment><comment><USER70> No. Just no.

</comment><comment><USER71> I see this useful for writing UserScripts/browser extensions.

</comment><comment><USER72> Nice framework but my eyes bleed when I see html and css in my js.

</comment><comment><USER73> This seems like the Perl-based web of 20 years ago.

</comment><comment><USER74> Oj also happens to be the fastest Ruby JSON parser.

</comment><comment><USER75> This dosen't really work at all with SEO

<comment><USER56> Not true. Google runs javascript code before scraping.

<comment><USER53> No, AFAIK, Google does not run Javascript code first without special accommodations. See [https://developers.google.com/webmasters/ajax- crawling/](https://developers.google.com/webmasters/ajax-crawling/).

There's a fundamental disjunction between today's search crawlers and these kind of dynamic Javascript apps that's just going to become even worse.

If anything, I think libraries like OJ point out the disjunction and therefore encourage discussion of what the future should be. HTML and Javascript have served us admirably, and given the nature of the web one wonders if we will ever get away from these technologies. That said, using one in isolation without the other (i.e. Javascript to generate HTML but not writing HTML) diminishes both as far as the usefulness of the "web" as we used to know it, at least.

I might even go so far as to say that fully dynamic browser apps, without the proper functionality for search engine indexing, are a direct threat to the business model and usefulness of search engines.

<comment><USER56> I'm sorry, but you are incorrect. It may not be officially supported, but they are doing it.

[https://www.google.com/search?q=uiji.js](https://www.google.com/search?q=uiji.js)

Check out the results for the 1st link (aakilfernandes.com/uiji.html) and then check the source code. You'll see that the entire body of the page is written with javascript.

<comment><USER53> I stand corrected - sort of - a bit more research shows the reality is "some dynamic/Ajax content" is indexed by Google, and not all search engines (i.e. Bing) are doing it yet.

For example, same search on Bing - [http://www.bing.com/search?q=uiji.js](http://www.bing.com/search?q=uiji.js)

References: \- [https://twitter.com/mattcutts/status/131425949597179904](https://twitter.com/mattcutts/status/131425949597179904) \- [http://www.biznology.com/2012/01/no-more-seo-worries-for- dyn...](http://www.biznology.com/2012/01/no-more-seo-worries-for-dynamic- content/)

</comment></comment></comment></comment></comment><comment><USER76> My adblock (GlimmerBlocker) breaks your JS.

</comment><comment><USER77> The fade effect make it feel sluggish

</comment><comment> vezzy-fnord I think I'll stick to markup.

</comment><comment><USER78> Oh good, another abstraction around html and css. Please murder me and this project.

<comment><USER34> Agreed. Universities need to start offering history courses on software development explaining why certain approaches were left behind. HN is full of "new stuff" that is just old stuff that we moved on from.

<comment><USER79> Hey guys... let's make a programming language... for non-programmers! Pretty wacky, eh?

It should also look like natural speech.

<comment><USER80> The basic premise sounds good...

<comment><USER79> Spoiler alert: it's COBOL.

</comment></comment></comment></comment></comment><comment><USER81> Love this, but I'll only adopt this way once it seriously becomes mainstream.</comment>


Apple's cash pile - The tech giant should give cash back to shareholders - <AUTHOR> http://www.economist.com/node/21549978

<comment><USER2> Paying dividends is a bad signal. That did not work well for Microsoft's share price. And even though OP argues that Apple will not repeat their fate, the argument is weak. There is only so much more iStuff that you could sell when everyone and their mother has an iPhone.

Paying dividends essentially signals that company does not see how to spend money and has no long-term strategy for growth.

<comment><USER3> Actually this not reflected in the empirical data. Studies of the data comparing longrun performance of companies with high payout to low payout ratios show significantly that average companies* perform better when they retain less cash.

This is counter-intuitive because a strategist would tell you that companies with more cash have more options, companies with less cash have to go through all the expense of going back to the market every time they need to make capital investments.

One thing that turns out to be the factor is agency costs. Companies with large cash hoards might waste money on bad or frivolous projects or more often bad, overpriced acquisitions.

In apple's case they have more cash than they can reinvest in their own business. The market could get better returns on that cash than apple can. Therefore the market will value the cash on Apple's books at discount to it's true value. The cash is discounted by apple's low sub-market rate of return on that capital and by the implicit risk that management might any day choose to do something dumb with it.

Instead companies that have to go to the market more often to raise cash, that have to file more prospectuses, turn out to be more transparently run and more accountable to shareholders. In the long run managers who "have to open the kimono" more often, turn out to perform better for shareholders.

When Microsoft announced the first huge one time dividend in 2003 or whenever it was, something funny happened. When they transferred X billion dollars to shareholders, their stock should also have dropped by exactly X billion dollars reflecting the value transferred out of the company. Instead their market cap only declined by 0.8X. Meaning than hundreds of millions of dollars of shareholder value was created out of nowhere. This was because the cash was worth that much more to shareholders who had a use for it than in the of microsoft who couldn't do anything with useful with it.

The 0.2X was the implicit discount of the value of that cash on MSFT's books that was unlocked by setting it free.

In fact because dividends are hard to take back, a dividend usual signals to the market that management have confidence in future earnings growth. Stocks usually jump on dividend announcements even though theoretically it shouldn't make a difference. That's the signalling effect.

*the big caveat being that APPL famously never performs or does anything exactly like an average company.

</comment></comment><comment><USER4> My problem with this, and all other stories on the same theme, is "Why?" Why does Apple NEED to do anything with its cash reserves?

The story says: "Last month Mr Cook admitted that the firm has more cash than it needs for its operations. It's a nice problem to have. The obvious solution would be to give cash back to shareholders, either via dividends or share buybacks." They claim having more cash than they need as a problem, and then spend 5 paragraphs detailing solutions, without further explaining WHY it's a problem.

Speaking as an (extremely minor) shareholder, I have no desire for dividends or anything else. My AAPL portfolio has gained 100% in 2 years, that's good enough for me.

<comment><USER5> I am also an apple investor. If they have $50B of cash they have no use for, then they are forcing me to be invested in government bonds. I'd rather have the money myself, and invest it in something that gets better than a .5% annual return. Using the dividend to buy more Apple stock would be better than the current situation.

<comment><USER6> > If they have $50B of cash they have no use for

Not the case and not what was stated.

They don't need those for immediate ops right now, but having tens of billions readily available is a great chip when discussing deal with manufacturers. It means you're able to put billions on the table upfront at a financial moment's notice. Apple's billions in the bank are a major asset in their negotiations.

<comment><USER5> We can bicker about the amount, but the meaning of "more than we need to run the company", means there is some that is of no use to the company.

I perfectly agree that Apple should keep a massive cash horde to fund future investment.

</comment></comment></comment></comment><comment><USER7> I'll say it again. Apple should buy Disney because they can provide Apple with gold plated content, it would actually be a halo brand for Apple, and their worldwide brands are highly compatible.

When Apple had $30 billion and Jobs was alive, it was possible for Apple to take control. Today they could buy all of it at a premium and still have $10 billion left over.

<comment><USER8> So you want them to be like Sony, who has gone down the drain since purchasing entertainment businesses? I would prefer Apple to continue doing what they do.

<comment><USER7> Sony is an interesting comparison. But they haven't had an iconic product associated with their brand since the BetaMax, and I don't think anyone could differentiate their content from Fox in the way that Disney's content is readily identifiable.

I.e. name three specific Apple products and three Disney movies - now try that with Sony electronics and movies.

<comment><USER8> What about the Walkman or Playstation?

</comment></comment></comment></comment><comment><USER9> Actually, this is easy: If Apple thinks the NPV of holding the money is greater than the NPV of not holding it, then they should do so.

</comment><comment><USER10> I see a lot of posts like this one talking about how apple NEEDS to do something to lower its stockpile of money but none of them seem to explain why. could someone tell me why holding $100 billion in cash is worse then doing stock buy backs and or issuing dividends if the market takes into consideration its large cash reserves when pricing its stock.

</comment><comment><USER11> Just to give some perspective on how much money Apple has, they almost have enough to re-build the US Interstate Highway system ([http://en.wikipedia.org/wiki/List_of_world%27s_most_expensiv...](http://en.wikipedia.org/wiki/List_of_world%27s_most_expensive_transport_infrastructure)) or construct their own space station (<http://historical.whatitcosts.com/facts-space-station.htm>)...

The article hits on a key point, though. Consider that during Jobs life he saw giants like AT&T and IBM falter, and other giants like Microsoft rise from nothing, and then falter. He used to tell a story about how they were 1 week from defaulting on payroll when he returned in 1997. I think he certainly wanted to keep the money for a "rainy day" scenario.

Which brings me to the most interesting thing that Apple could purchase: they could afford to pay an average salary of $300,000/yr to _every one_ of their employees for _5 years_ with absolutely no revenue, and they still wouldn't exhaust their bank vault. If it were up to me, I would say they should start something equivalent to Bell Labs or PARC, but they won't. To do so would be antithetical to the very character of the company. In other words, quite the bind to be in...

<comment><USER12> Apple is a publically held company. Disposing of profits by giving it all to employees would be a wonderful way to create an instant shareholder lawsuit.

The cash held by Apple is built in to its share price. If a stock holder wants some of that all they have to do is sell some shares. Undoubtably there are some tax considerations regarding capital gains vs. dividends but the fact remains that if Apple distributed a significant amount of its cash to shareholders, then the share price would inevitably drop by the same amount.

</comment></comment><comment><USER13> First, quite a lot of the money is overseas and at the current tax rate isn't coming home.

At this point, I would favor acquisitions over cash to shareholders. Although, being cautious in this economy is probably a good thing.</comment>


Hurricane Sandy and AWS: Migrating Octopart Out of us-east-1 in a Hurry - <AUTHOR> http://octopart.com/blog/archives/2012/11/hurricane-sandy-and-amazon-web-services%253A-migrating-out-of-us%252Deast%252D1-in-a-hurry <comment><USER2> Ok, if you're looking for a startup idea, here you go a free one on the house :-)

"EjectorSeat" - EjectorSeat is the hip cool way to create a current, usable, set of scripts which can move any AWS/EC2/Linode/Heroku/... (start with AWS/EC2) instance from where it is, to somewhere else. By using EjectorSeat all of the changes and specs you have on your install are automatically documented into its configuration and data location databases so that when the time comes to pull the yellow and black handles, you will know that your install is being migrated, and better yet, when its done migrating one push of a button and blam! its up and running.

\</comment><comment>-----

It seems like this should be possible to package up (it will take a bit of work of course) but its the 'copper' option (of the silver/bronze/gold nomenclature) for disaster preparedness. Basically you don't have the funds to maintain two instances all the time, this lets you move the one you have when you need to.

Of course like real ejector seats it will have failure conditions (like flying inverted at 50', bad time to eject) but it could provide an ops guy with a bit of piece of mind.

<comment><USER3> Most of the hard work is already done for this: Puppet, Chef, etc.

<comment><USER4> CloudFormation should also be helpful here.

<comment><USER5> Yeah - but what would really help is if EC2 had more tools to support cross region moves†.

Hint, hint…

\--

† I too did an us-east-1 to us-west-2 move on Monday, and it was unfun.

<comment><USER6> They provide pretty good tools already. If you leverage their API and S3 you can migrate AMI's and EBS's across regions quite effectively. Could the tools get better, yes. But it's not as hard as it is often made out to be.

<comment><USER5> I just did this Monday, and there is 0 support that I could find for moving ebs volumes cross region. I used netcat to push the data, which seems profoundly wasteful.

I'd love to hear of an s3 based approach.

<comment><USER6> You can use this, many people have reported it does well. I have not used it.

<https://cloudyscripts.com/tool/show/5>

You can also use the APIs to do that S3 copy I mentioned. Here are one of the many write ups of that technique.

<http://alestic.com/2010/10/ec2-ami-copy>

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> RDS/EBS snapshots being bound to their region is a big stumbling block. Especially for RDS, because the only solution is mysqldump (or similar) and that not only blocks the production database but takes hours for databases above 10 GB. So at the end of this you have a very out-of-date backup that you can transfer to the other region.

Cross-region snapshot mirroring would be a great enhancement feature for AWS.

<comment><USER8> You might just consider setting up a dedicated slave MySQL database on a smaller instance in the west region just for the eventuality that you need to spin up a master there. Then you can just snapshot, copy to ephemeral, and go from there.

</comment></comment><comment><USER9> "EBS snapshots cannot be moved between regions"

Not true. I've done this using Ylastic. See <http://ylastic.com/features.html>:

"Migrate EBS linux snapshots between regions."

"Migrate EBS windows snapshots between regions."

Takes a few minutes to kick off and does it all for you.

<comment><USER5> As you've used it - how long does it take? I read up, and I decided they where probably just making a new EBS volume in the new region, `netcat`ing the data across, and taking a snapshot of that new volume, with the `netcat`ed data.

So I did it by hand - that way. It it'd be pretty easy to tell if this was the case, because it really wouldn't be fast….

<comment><USER9> It's not fast, they send you an email when it's done. It was a while ago now, but I recall it taking about 30 minutes before I got the email.

</comment></comment></comment><comment><USER10> I know this is a little late for your case but you can migrate snapshots from 1 region to another. We spend sunday moving from US-East 1 to US-West 1 and took 2 hours to setup our entire infrastructure consisting of 20 servers & about 180 GB database

There are several options

1\. Manually - <http://alestic.com/2010/10/ec2-ami-copy>

2\. Automatically via Scripts a) migrate-ebs-image.pl - <http://search.cpan.org/~lds/VM-EC2/bin/migrate-ebs-image.pl> b) CloudyScript Migrate SnapShot - <https://cloudyscripts.com/tool/show/4> c) CloudyScript Migrate AMI - <https://cloudyscripts.com/tool/show/5>

3\. Commercial Services a) <http://ylastic.com/> b) RightScale

* ylastic is really cheap at $25 / month * I used the perl script migrate-ebs-image.pl, super simple to install and use. * CloudyScripts has open sourced their Ruby gem so you can build on top of it. They also have a free web form you can just use (but may not be secure enough). But you can launch their AMI in your own instance which should be secure

Hope that helps for next time!

<comment><AUTHOR> Thanks, these will be useful for next time. Hopefully AWS will add the capability to migrate the EBS snapshots to the console soon.

<comment><USER10> would be nice for sure. luckily AWS builds the API first then builds it into the console, so many you can still get the job done just takes a little digging. feel free to reach out if you ever run into another situation like this</comment></comment></comment>


Radio Mistakes, Moscow 1941 - <AUTHOR> http://www.strangehistory.net/2018/02/25/radio-mistakes-moscow-1941/ <comment><USER2> TL;DR: There are reports that somehow the anthem of the Nazi Party was played on air by a Russian radio station while the German Army was apparently on the verge of capturing Moscow.</comment>


The Qwiki Experience - <AUTHOR> http://blog.zukmo.com/?p=52

<comment><USER2> The text to speech is slow and it is a drab. I can open up Wikipedia and run through the content 5 times faster than that. You will have lot of impatient users waiting for the information they actually want. It is like calling your bank up and listening to their long IVR menu when actually you want to report your stolen credit card.

Imagine waking up every day to the same drab slow dull voice that tells you about the day's weather.. !!

</comment><comment><USER3> I tried Qwiki too. Frankly I don't get it. Taking a few sentences from Wikipedia and then converting that to speech is not necessarily an information experience. Wonder what the Techcrunch Disrupt panel found exciting about Qwiki. It seems to matter if a startup has founders with some pedigree or at least associated with people with pedigree. I am sure there were better start ups in Techcrunch Disrupt.

</comment><comment><AUTHOR> Qwiki, this year's Techcrunch Disrupt winner seems to have a long way to go before it can really be an "Information Experience" that they claim it will be.</comment>


Twitter gets venture round anywhere from 1-5MM - <AUTHOR> http://www.techcrunch.com/2007/07/26/twitter-gets-their-venture-round/

<comment><USER2> I'm confused by services like twitter and heyhan. How is money made when the platform is difficult to monetize and easily repeatable? I suppose both could use text-ads.

<comment><USER3> If you attract a large number of eyes, you can always monetize them somehow. Also, at this point, it's unlikely Twitter-ers would use a clone of Twitter, because everyone is using Twitter.

<comment><USER4> I think this statement will be repeated for years and years. The problem is that at some point it will only be used to poke fun at our past selves for taking the idea too far.

<comment><USER3> If you have a large audience, and you can figure out what at least one person wants, you can monetize the audience. Are you thinking you're going to make millions your first try or something? Small steps.

<comment><USER4> Just don't turn a good rule of thumb into a religion.</comment></comment></comment></comment></comment>


Sentient code: A look at Stephen Wolfram's new, insanely ambitious, paradigm - <AUTHOR> http://venturebeat.com/2013/11/29/sentient-code-an-inside-look-at-stephen-wolframs-utterly-new-insanely-ambitious-computational-paradigm

<comment><USER2> A terrible puff piece. First of all, A New Kind of Science is mostly controversial (in scientific fields) not because what it says is controversial, it's not - actually sometimes trivially accepted as true - _wait, what there are emergent phenomena that can be described by simple mathematics who 'da thunk it?_ But rather because it almost attempts to redefine "science" which is somewhat dangerous.

Search engines aren't good at that, Wolfram argues, because they're too messy. Questions in a search engine have many answers, with varying degrees of applicability and "rightness." That's not computable, not clean enough to program or feed into a system.

 _"We want to be right," Wolfram told me. "Making the world computable is a much higher bar than being able to generate Wikipedia-style information … a very different thing. What we've tried to do is insanely more ambitious."_

This is exactly wrong, and perhaps Wolfram is a victim of what I like to call the "Lt. Cdr. Data fallacy" that sometimes afflicts AI - that AI is something which ought to our fuzzy world and assigns a definite binary result which is always or almost always going to be correct and perfect in every way. To take the example in the text, "Where is the ISS". There is not really one right answer. You could give precise siderially defined coordinates of the International Space Station, but, maybe "10 degrees to your left, and 20 degrees off your vertical axis in the downward direction, 12790km down" is a more correct and useful answer. Or, maybe if you're at the sandy spring transit station in Atlanta Georgia, "first right after the parkway on mount vernon" is correct; interpreting ISS to mean the former "internet security systems, inc" (which is a query that google "understands"). [https://maps.google.com/maps?q=sandy+spring+transit+station+...](https://maps.google.com/maps?q=sandy+spring+transit+station+georgia+to+ISS&saddr=sandy+spring+transit+station+georgia&daddr=ISS)

Sometimes there just isn't one universally correct answer.

Having said all of this, I have tremendous respect for Mathematica, which really helped me get through Grad school, mostly because their systems of differential equation solver is quite nice, and their graphing package was superior to excel.</comment>