There is no more Perl at JP Morgan - <AUTHOR> https://thehftguy.com/2020/06/26/are-banks-still-using-perl-in-2020-the-answer-is-no/ <comment><USER2> 98 open jobs at JP Morgan with Perl in the description: [https://jpmc.fa.oraclecloud.com/hcmUI/CandidateExperience/en...](https://jpmc.fa.oraclecloud.com/hcmUI/CandidateExperience/en/sites/CX_1001/requisitions?keyword=Perl)

Including many that seem pretty clear Perl is involved in a substantial way: [https://jpmc.fa.oraclecloud.com/hcmUI/CandidateExperience/en...](https://jpmc.fa.oraclecloud.com/hcmUI/CandidateExperience/en/sites/CX_1001/requisitions/preview/210005700/?keyword=Perl+5)

<comment><AUTHOR> Looking at the first 10, none of them are asking for Perl specifically, they're generic job listings with a point "N years of experience in Bash, Perl, Python, Java..."

</comment></comment><comment><USER3> I'm guessing Deutsche Bank is hiring Perl developers for fun then?

[https://db.wd3.myworkdayjobs.com/en-US/DBWebsite/job/New- Yor...](https://db.wd3.myworkdayjobs.com/en-US/DBWebsite/job/New-York-60-Wall- Street/Associate--Technology-Service-Specialist----KP4721567-_R0064460)

EDIT: since it was silently changed: This was originally titled and submitted as "Are banks still using Perl in 2020? The answer is no." (still visible in the URL slug)

</comment><comment><USER4> This is hardly a surprise. No matter if you like a language or not, you have to acknowledge that we don't develop software in a vacuum and we cannot ignore market trends. Don't fall in love with your technology [0].

(I won't comment on the Python 2 rewrite though)

I like Perl a lot. Out of the usual, interpreted dynamic languages, it is still my favourite. It's fun, incredibly expressive, got some things right early on (CPAN) and the community is probably the most entertaining out there.

It also caters to a kind of developer that no longer exists, or at least is in the minority now.

I will keep it as a sort of dirty pleasure for myself. Among the likes of Forth and Lisp.

[0] [https://prog21.dadgum.com/128.html](https://prog21.dadgum.com/128.html)

<comment><USER5> > It also caters to a kind of developer that no longer exists, or at least is > in the minority now.

The one developer I met who liked Perl was quite the character. He thought in a certain way I envied. Once he rewrote a bash script into Perl just for fun (and to confuse the rest of us). As a gratuitous side effect, the Perl script cut execution of the same task from over 1m in Bash to a matter of seconds.

I've resolved to learn it myself now, even if it nudges me more towards a mode of thinking. There's still plenty it can do.

</comment></comment><comment><USER2> So a high effort project to convert from a codebase with a supported interpreter to an EOL interpreter. Congrats, I guess.

</comment><comment><USER6> My employer has banks, brokerages and RIAs as customers.

I don't know whether any of them use Perl. I can tell you that if they use Perl, it has never caused a problem.

We use a fair amount of Perl, and it's a good tool.

</comment><comment><USER7> Why would you put years of work migrating from a supported language to one that hasn't received support since 2013 and brag about it? I'm so confused

<comment><USER8> RHEL's distribution of Python 2.6 is still supported as part of the OS. As the author noted, the scripts were written to be forwards compatible with Python 3 for when the bank upgrades to a newer version of RHEL.

</comment></comment><comment><USER9> There's a distinct whiff of "I hate Perl and must stomp it" in this guy's articles.

<comment><USER10> Seems to be common amongst pythonistas. I've run into their tired bashing of perl for 20+ years.

I use perl daily. And Julia. And C. Python more like weekly.

Always select the right tool for the job. Changing code that works, and is critical should not be undertaken lightly. Most especially not of irrational dislike of the current implementation language.

<comment><USER5> > Seems to be common amongst pythonistas. I've run into their tired bashing of > perl for 20+ years.

Perlphobia must stop.

      say("no");
      # make it
      die();
      # Python's easier? That's a lie!

</comment></comment></comment><comment><USER11> Yeah, I'm not convinced. Not in the slightest. JPMorgan has something like 250,000 employees. Just think of how many divisions and departments there are. It might be that someone ran a report at a high level over some major projects and said, "We're not using it." I guarantee it's still there in pockets still being used and still being maintained.

<comment><USER12> I think you'll need something more than a feeling, to disagree with _the person tasked with finding uses of Perl at JP Morgan_ on how much Perl is used at JP Morgan

Also it sounds like you didn't read the piece as this comes right at the start:

> search covering repositories with 50M lines of code and thousands of servers

<comment><USER11> Sure. Let me explain.

1\. You notice how he said "Investment Bank". Guess what, that's not their entire business....not even in the slightest. Not even the most profitable. When I was there, they sold a significant portion of their investment services to buy more commercial, which is in an entirely different line of business. They aren't connected. Their systems are separate.

2\. I worked there. I understand the absolute magnitude of how large their code bases are. The legacy software, the business processes. 1000s of servers, is nothing in a company that size. The division I worked for was a dust spec compared to the size of JPMC, and we had something like 300 servers on our own. We were a rounding error on the division's balance sheet. I should say, a division, of a division, of a division of a Line of Business. Multiply that by orders of magnitude and you begin to understand the size of their operations. Let me put this into perspective. A quick line count of the project I'm on, with 4 people and started 2 months ago (with npm packages granted) has over 500,000 lines of code. How big do you think JPMC's code bases are?

3\. Do you honestly believe that a company that size tasked 1 person with just "removing PERL". Most of it was not being used anyway, and he "just did it." He just "searched" the repositories. How exactly do you think that worked? Do you think an EVP, a chief, just tasked 1 person with search "the codebases" across multiple lines of business? He might have done it for a division, a part of a LOB. I'll give him that, but not JPMorgan as a whole not even the the entirety of the investment arm. Think about how many legacy systems use PERL everything from legacy systems, to commercial ETLs. The amount of business knowledge held in those scripts, and making a mistake, even a minuscule one will cost potentially millions of dollars. What did he search? Did he do a Git search, or SVN, or CVS, or event maybe VSS? How many file and network shares? Did he have access to everything? All the devops stuff? What about all the things that are maintained by contractors and consultants? How about those?

<comment><AUTHOR> Author here. Definitely great questions. I would like to reply but this is touching sensitive information that I don't think I can publicly disclose. ^^

What I can maybe say, is that the scope is touching JP Morgan, the corporate and investment bank with maybe 40 000 employees. It is much broader than you think.

</comment></comment></comment></comment><comment><USER13> This guy may have gotten Perl out of his part of the JP Morgan world, but JP Morgan still actively uses Perl. It's not as big as it once was, but there are teams still developing and deploying Perl.

<comment><USER14> This is what I figured. My experience of SW development at a merchant bank is siloed teams using their own development tools to support their banking operations. There was never a company wide mandate on using/not using some technology.

<comment><AUTHOR> That's not the case in JP Morgan. Development is very centralized.

There are like 3 to 6 major platforms used inside of JP Morgan, depending how you count (the oldest one is deprecated and being migrated away which will never complete, while the newest one is nowhere near working and will not have anything running for a long time).

The largest one regroups maybe 30% of all the developers and developments in the firm.

The Perl system was underlying on of these platforms, and has clients for use in all other platforms, so it was quite ingrained across the entire company really.

</comment></comment></comment><comment><USER15> JPMorgan is only one bank; it's still used in plenty of banks. What is the point of this article anyway? Proving 'perl is dead' as it says in the epilogue?

<comment><USER10> Yeah, the article was weak. I must have missed the compelling reason to switch off of a live language to the EOLed one.

And ... did they actually, really do that, for a critical piece of infrastructure, because someone dislikes perl?

That should worry bank customers, shareholders, etc.

Business and tooling decisions should be rational, and risk reducing. I don't see that this change met either of these criteria.

</comment></comment><comment><USER16> Im a Junior dev and I actually have been learning basic Perl over the last year. I think Perl is still useful in shell scripts and most of the time its faster than awk and sed. But I cant justify using it instead of Python for scripts or applications. I cant think of any advantage to using perl instead of python in 2020. Even if there is an advantage, any coder can read and write python without learning python whereas Perl scripts are a liability, few can maintain them. I would love to use Perl I think its powerful and especially I see use cases for it in data munging. But at the current moment it needs a killer app that can offer some clear justification over python.

I do think Serverless Perl could be a good idea though: [https://metacpan.org/pod/AWS::Lambda](https://metacpan.org/pod/AWS::Lambda)

</comment><comment><USER17> Their software is running on python 2.6 but they also have it working on 3.7?

Why?

Also this is some weird post, is this blogger famous? Because it's not of much substance.

<comment><AUTHOR> Because the servers ran on RHEL 6, so the application had to run on python 2.6.

Servers will be upgraded to RHEL 7, so the application had to run on python 2.7 too in prevision of the upgrade very soon.

Then servers will be upgraded to RHEL 8 maybe 5-10 years later, so the application better work on python 3 too.

It is not glamorous but it's the practical way to make critical software work and continue working for some period of time. I think we can all agree that we don't want our banks to break every 3 months accidentally due to the newer release of whatever.

<comment><USER18> > Because the servers ran on RHEL 6, so the application had to run on python > 2.6.

pyenv runs on RHEL 6 yeah? Does Python 3 not?

<comment><USER3> Is pyenv and the Python 3 it wants to use in official/supported packages? If not, it doesn't exist for many IT departments in such cases.

</comment></comment></comment></comment><comment><USER19> so perl is not actively used and developed by the perl community? i would have sworn i saw a new release this year?!

<comment><USER20> Version 5.32 was released 6 days ago:

[https://metacpan.org/pod/release/XSAWYERX/perl-5.32.0/pod/pe...](https://metacpan.org/pod/release/XSAWYERX/perl-5.32.0/pod/perldelta.pod)

</comment></comment><comment><USER21> I call bullshit. Every macbook on this bank (and elsewhere) has several perl programs running daily and supporting the jobs of the people who own them.

<comment><AUTHOR> JP Morgan doesn't support macbook. I've only ever seen one employee in my time there with a macbook, who's had to go out of his way to procure it and he had regular issues because it was unsupported, issues like DNS not working.

</comment></comment><comment><USER22> I'm not surprised that Perl is being phased out, but was JPMC really that big on Perl? IIRC, I worked at JPMC in NYC over 10 years ago and IIRC they never had the kind of centralized Perl infrastructure like Morgan Stanley did -- though after the BankOne acquisition, things started getting streamlined a bit.

</comment><comment><USER23> Nothing against Python, but I'd have expected the choice of a little more (statically) typed language for such a critical application (also considering future maintenance). Any reasoning behind why?

</comment><comment><USER14> I only ever used perl for regular expressions from the command line when sed failed me. Perl just doesn't have the mindset of python IMO.

</comment><comment><USER24> Yep. No more DHTML either.

</comment><comment><USER25> How about APL?

</comment><comment><USER26> > Are banks still using Perl in 2020? The correct answer is no.

> There is no more Perl at JP Morgan, the largest investment bank in the US. > The last Perl code was decommissioned in 2019.

I see the situation at JP Morgan now extrapolates to all banks globally.

I am glad that JP have done something sensible here, though.

> Nope, not python 3. Think 2018-2019 so no python 3 in sight.

What. That was literally last year. We all knew Python 2.7 was going to be EOL on January 1st 2020.

I know a lot of these legacy banks/financial institutions seem to operate in a time-shifted bubble a good few decades in the past, so maybe that explains it?

<comment><USER27> It's not even python2.7, they went with 2.6. A version that reached end of official support in 2013. All because that's the default for RHEL 6.

It's not hard to build RPMs of newer and/or supported versions of Python. You might even find it in EPEL. I get being risk averse, but if you're going to make the change, move to something sensible that your developers will want to work with.

<comment><USER28> On the other hand Python 2.6 will be supported on RHEL 6 for as long as RHEL 6 is supported.

Of course this still means having to switch again in a few years time but that's a problem for future JP Morgan.

<comment><USER2> RHEL 6 EOL is 11/30/2020.

There's "extended support", but no patches, not even security patches.

Edit: Apparently I was wrong about some security patches, but ELS sounds complicated: [https://access.redhat.com/discussions/2399461](https://access.redhat.com/discussions/2399461)

<comment><USER28> It sounds like you can pay extra for security patches until 2024: [https://access.redhat.com/support/policy/updates/errata/#Ext...](https://access.redhat.com/support/policy/updates/errata/#Extended_Life_Cycle_Support)

</comment></comment></comment></comment></comment><comment><USER29> Oh, are we writing blog posts to answer questions no one asked? I have a few more ideas then:

\- Are state unemployment agencies using Nim in 2020?

\- Are aircraft carriers using Ruby on Rails in 2020?

\- Are hospital bed firmwares using Excel VBA Macros in 2020?

<comment><USER18> For some reason, the last one feels very plausible.

</comment></comment><comment><USER30> I dont believe this. Maybe it's no longer used for "core banking services" but companies the size of JPMorgan have subdivisions that are as big as small/medium sized companies.

There must be a lot of software written in <whatever language> that is still used inside the company.

<comment><USER31> I never worked at JPMorgan but a lot of the investment banks went towards a single platform for everything. JPMorgan had Athena, Bank of America had Quartz, and they both use Python. Goldman Sachs had something similar whose name I forget (slang?)

At least in 2011 when I last worked in the industry, this sort of infrastructure was replacing the ad-hoc data-munging scripts that people used. It was even slowly eroding some of the Excel-based workflows designed by less software-engineery teams. 10 years later, I'm guessing it's only doing more than it was back then.

<comment><USER30> That's true. Several companies I know are pursuing such endeavors. It's often even battle between Java & .NET as they are trying to focus on a single stack.

<comment><AUTHOR> The comment you reply to happens to hit the nail on the head. Some perl was slipped deep into some platform in the 2000s.

While client software could be python, java or C# (usage has evolved quite a bit over the decades), they ultimately called and depended upon a bunch of Perl on some servers.

</comment></comment></comment></comment><comment><USER32> For some reason people like to compare perl to cobol. Perl fell out of usage more like lisp or tcl, mostly a failure to deliver on some of its promises which proved to be market advantages for others. The influence of latin is obvious.

Let's hope the windows 7 phase is over. I personally think perl 5 was a mistake, perl 4 was more fun and minimalistic ... just like javascript 5 vs typescript.

Commercial things have a way of ruining fun.

<comment><USER33> and one has to keep investing from one's personal savings to learn new languages and tools every year, even in one's near retirement age!!</comment></comment>


Should I block all of China from my online store? - <AUTHOR>

So, I have a not-really-in-beta-yet online store I'm developing in Drupal, aimed at 3D animation geeks. I've been a 3D developer since '85, and have some pretty advanced stuff going into my online store (see www.flixor.com, my technology company.) Anyway, perhaps because I globally patented my more advanced technology, companies in China are constantly crawling both my not-really-open online store and my technology company's site, consuming some significant bandwidth. But more important: their constant traffic impacts my work getting the store open.
I've also noticed that every variation of my technology company's name has domain squatters in China. Plus my patent in China receives challenges, but I've survived them all so far.
At this point, as I get closer to launching my store, their crawling and seeking access to my backend is getting out of hand. Last weekend an IP address in China consumed all public data from the site. I can, through my Drupal backend, simply ban all of China's IP range.
Would that do any good? Any suggestions?
This looks promising: http://www.parkansky.com/china.htm <comment><USER2> Anything you do is going to impact performance on your site. It sucks, I'm sorry.

If you go the .htaccess route, every single new connection will get pattern matched against the _deny from_ patterns. It's a bit better using CIDR notation, but still, every connection will take a slight hit as the pattern match is run. I assume that Drupal does a similar pattern matching scheme to block/permit access.

A determined adversary will realize that you're blocking by IP addresses and resort to something like TOR or a VPN to crawl your site.

Another option is to use something like IPTables with some intelligence on your server site to dynamically block anyone slurping lots of data off the site (but be certain to whitelist Google/Bing/other "friendly" crawlers).

You could try something slightly bizarre: on detecting adversarial traffic from what you suspect is a Chinese client, return the complete works of the Dalai Lama, a history of tibet, possibly treatises on Falun Gong or the true history of Tiananmen square, and put the Great Firewall to use for you. Depending on the ISP and the day's censorship regime, you might get the GFW to block your site from access from behind the GFW. You don't care, you don't want the traffic anyway, and from the GFW's perspective your site will be marked as a "dangerous" site with inappropriate content for consumption in China.

<comment><AUTHOR> Brilliant, I love the idea of sending them the true history of Tiananmen square!

<comment><USER2> If you can, look at reactive responses, rather than proactively blocking everything (and thus impacting site performance for all potential customers). So something in drupal or mod_security which watches inbound traffic and if a pattern emerges, then respond until the traffic dissipates.

Another thing might be to require a login for the portions of your site where you want to protect the content, or which are dynamic and for whatever reasons caching isn't helping mitigate the load. Again, determined adversaries will just add the login to their scripts and carry on, but you can now block by the authentication rather than by IP address.</comment></comment></comment>


Upload Files via Web Search - <AUTHOR> https://blog.filestack.com/content-cookbook/upload-files-via-web-search/ <comment><AUTHOR> Greetings! Let me know if you have any questions about working with the configuration object as you pass it to the File Picker. You can ping me here, or catch me on Keybase: [https://keybase.io/DavidCanHelp](https://keybase.io/DavidCanHelp)</comment>


Ask HN: Where should I advertise an iPhone App? - <AUTHOR>

Background:
We have just completed the code to our first non-game iPhone App and are looking to do the difficult bit: Marketing.
We have, for the first time, saved for an advertising budget and I am currently in the throws of writing a marketing plan.
We've got a small war-chest to start us off: not much, maybe a month-or-two's advertising budget with some of the smaller sites, but it represents a year's worth of contract work and hard-won savings.
I'd love to advertise with The Deck and Daring Fireball, but it we would blow our budget in a few weeks. Plus, our core customer is probably younger and a less design oriented than these sites.
The app itself is a revolutionarily simple take on a personal finance app that tracks your budget for you in a fun way without requiring a single receipt.It's aimed at the kind of person who throws their receipts in the trash.
Our tagline is "Money Management for Mere Mortals".
I'm mostly interested in hearing from people with experience, but obviously any useful tips would be gratefully received.
Who/what has worked for you and your app? <comment><USER2> You might have already thought of the following, but here is a couple of ways:

1\. Offer a lite version which is free, and try marketing that and leveraging on those users to upgrade to a paid app

2\. Approach iPhone app review sites and pitch the app to them for a review. (you might also consider advertising in these app review sites to begin with and to gauge the initial response)

I agree with you that blowing away your hard earned money on a big marketing spree _might_ not be a wise decision. So, starting off with a smaller site and watching the initial reactions would give you more confidence on what to do next.

All the best :)

<comment><AUTHOR> Thanks for taking the time.

I'm slightly wary of a free lite version, at least at first, as people who get things for free tend to be more inclined to leave a bad review.

I also think that, having spent a year of my life on this that it deserves customers who want it and are willing to pay for it.

<comment><USER2> "I'm slightly wary of a free lite version, at least at first, as people who get things for free tend to be more inclined to leave a bad review."

If someone were to take his/her time to post a review - it has to be something very extreme - either should absolutely hate the app or really love it. From the reviews I have seen on the app store, it's actually people who paid for an app and didn't like it who make a fuss..

I guess at the end of the day, there is no easy way about this. If you want leads, you need to either have a free version which will allow more people to try it and hence convert, or else put in the advertising to go for the paid customers. It's a situation that's quite similar to what I am facing too, but there is no easy way out of it. The viral loop doesn't occur always :)

<comment><AUTHOR> I've been trying to find the blog post (with figures) that showed that people who pay more for an app tend to rate it higher but I can't find it sadly, so take that with a pinch of salt.

I had thought it was on the taptaptap blog.

However, as an ex live comedy promoter I know from experience that if you let people in free they never laugh as much and are far likelier to be the ones that heckle. This seemed to be the case even if they were a fan.

Physical/monetary buy-in correlates very strongly with emotional buy-in.

</comment></comment></comment></comment><comment><USER3> I'm currently working on a non-traditional "pay for downloads" site specifically targeted at iPhone apps to begin with. I have taken the plunge, registered as an LLC, and the site is almost completely built (expected launch in < 2 weeks). I will post on HN when I do launch but if you want to know more about it or are interested in being part of the launch shoot me an email at matt dot sencenbaugh at gmail

Sorry for the plug.

As far as a lite version of apps I think its a dangerous path.... I think it can be a valuable tool but only if you find the right balance between what features to include and what to lockdown in the lite version. In the end I think it really depends on how the initial launch goes. If you find that you aren't getting much traction perhaps you should release a lite version for a few days. If after a few days you notice that the lite version hurts your sales... simply remove it.

<comment><AUTHOR> Can you give a little more detail about what you mean when you say "pay for downloads".

Isn't that what Apple already do?

<comment><USER3> Here's the idea behind my company: iPhone developers want people to download their app. Generally they pay for ads through a service such as admob which has a terrible conversion rate. My company gives users paid apps for free and provides the developer with downloads.

Here's how it works from a developer standpoint: 1) You create a campaign. This campaign contains a multiple choice question that would be hard for someone to know that didn't actually buy the app. (aka whats the second persons name under the credits or something like that.... its partly honor system based although incorrect guesses are punished). 2) A user downloads your app, and answers the question you created. If they answer correctly they get paid the amount you specified (minimum of the price of the app).

In this way users get great apps and developers get their app out in the wild!

Does that clear things up?</comment></comment></comment>


The Debacle of Google Glass - <AUTHOR> http://recode.net/2015/05/12/the-debacle-of-google-glass/

<comment><USER2> My theory with accessory tech (Stuff you wear or use in public) is that adoption is _far_ more driven by whether or not it works within the existing social framework and rules of interaction we all tend to abide by in public.

Things like google glass and bluetooth headsets have this problem, and it stems from the fact that they don't properly signal to the people around you that you are occupied. We've all had that moment when we think somebody in line at the coffee shop is talking to us, but it turns out they are on a bluetooth headset. There aren't any social norms set up to handle dealing with that yet, so the technology quickly gets equated with being an asshole.

You might argue that smartphones buck this trend, but actually we have a long history of social norms built up around reading in public, and all the same cues and responses apply to smart phones.

Walkmen and ipods fit nicely into the existing rules of interaction because there's an obvious visual cue that the person is occupied (headphones).

Smart watches also suffer from this problem - wrist watches have been accepted accessory products for a long time, and the only sure way to use one offensively is to check it while in a conversation with somebody. So one of the major use cases is something you can't do without being rude.

</comment><comment><USER3> [http://hosted.ap.org/dynamic/stories/U/US_DRIVERLESS_CARS_AC...](http://hosted.ap.org/dynamic/stories/U/US_DRIVERLESS_CARS_ACCIDENTS?SITE=AP&SECTION=HOME&TEMPLATE=DEFAULT)

\- 1 million miles in self-driving mode.

\- 11 crashes.

This means about 1 crash of an autonomous vehicle every 90,909 miles.

[http://www-nrd.nhtsa.dot.gov/Pubs/812032.pdf](http://www- nrd.nhtsa.dot.gov/Pubs/812032.pdf)

\- 5 615 000 reported total motor vehicle crashes

\- 2,968,815,000,000 reported vehicle miles travelled

This means about 1 crash of a human-driven vehicle every 528,729 miles driven. So, human-driven cars are not hit as much as Google's. Maybe people hate them, so they run into them :D heh.

In seriousness, it's probably because where Google drives its cars there's much more traffic.</comment>


Seasonal Flu Shots Double Risk of Getting Swine Flu, Says New Study - <AUTHOR> http://www.theglobeandmail.com/news/technology/science/study-prompts-provinces-to-rethink-flu-p%3E%20lan/article1303330/

<comment><USER2> "Distributed for peer review last week," means not yet peer-reviewed. The statement in the article headline is doubted by most immunologists and is not reliably verified.

<http://norvig.com/experiment-design.html>

Earlier commentary from the Center for Infectious Disease Research & Policy:

[http://www.cidrap.umn.edu/cidrap/content/influenza/swineflu/...](http://www.cidrap.umn.edu/cidrap/content/influenza/swineflu/news/sep2409canada.html)

"So far, 'Investigators in other countries have looked at their own data and whether they could find similar observations, and none of the other countries have been able to find anything like that,' Kieny added. She said the findings could be real or could be the result of a study bias or other methodologic problems."</comment>


Deployment Tools and Techniques at Spotify - <AUTHOR> http://www.hakkalabs.co/articles/deployment-tools-techniques-spotify

<comment><USER2> Mad props should be given to these guys for (IMHO) Doing It Right(tm). They're managing all their packages via ONE package interface (apt-get), and are able to reap the rewards of being able to more easily manage their knowledge, build tools, and build processes - at the end of the day, it's just _simpler_ than having to go "Oh, this is installed via apt-get, these are installed via gem- install, over here these are installed via setup.py..." The whole gem/egg/cpan/whatever concept has serious issues when moving from the developer's laptop to the production environment, and I wish more folks took the time up front to do it natively, like Spotify and Hynek.</comment>


Turn Off Your Push Notifications. All of Them - <AUTHOR> https://www.wired.com/story/turn-off-your-push-notifications <comment><USER2> Ok, this article covers annoyance problem of push notifications. What about from the privacy point? Does the app provider know more about you have them turned on.</comment>


Security Incident - <AUTHOR> http://en.blog.wordpress.com/2011/04/13/security/ <comment><USER2> Using the phrase "low level" to describe someone gaining complete control of your systems is not something you see in a general PR release for an incident. The friends and family I have recommended wordpress.com to are likely to misunderstand the importance of this event.

<comment><USER3> Agreed, I think that was a poor choice of words in this case. To be fair, communication skills often take a temporary hit in these situations when you're still actively coping.

</comment></comment><comment><USER4> Good reminder how honesty and transparency are essential in surviving issues like this. There are currently two PAGES of comments on this post, overwhelmingly positive and thankful for this sort of early disclosure.

This reminds me of a talk by Gary Vaynerchuk where he joked that he wished some of his consulting clients (via <http://vaynermedia.com>) would screw up badly so they had an opportunity to apologize. Strong bonds are formed in times of trouble.

</comment><comment><USER5> This is why startups should always provide users the option to change their password, don't delay this essential funcitonality please.

</comment><comment><AUTHOR> They didn't post much details, but if you have accounts at wordpress.com/.org, you know what to do (change passwords, etc) :)

</comment><comment><USER6> Is cleanup on Wordpress.com/org something Sucuri.net can help with? Is there an opportunity for Sucuri to do something at a special rate for affected HN'ers?

<comment><USER7> This is an issue effecting WordPress.com, where users have no access to the source code.

Given you go on to mention WordPress.org and even mention a discount for HN users, it feels as though this is a pitch for a specific vendor..? :(

<comment><USER6> I can see how it might appear to be that way. For the record I have no relationship with Sucuri whatsoever. I do however know that they engage in WordPress cleanups and (from what I've heard independently but YMMV) they're rather good at their job. That's why I asked because sucuri submitted the post - I'd rather the HN community got a good deal and I asked the question than people paid over the odds when they could've got something better.

I can see how it looks like a pitch, but in some ways it's an anti-pitch or a pre-negotiation. They specialise in wordpress compromises, we deal with completely different stuff but in the security space. We can deal with your compromised wordpress install but sucuri does this day in day out - we deal more with your network being broken into. I thought it might be good to highlight the poster's speciality in the area, and (cheekily) ask for a HN discount.

Apologies if I've betrayed some HN etiquette here, that was not my intention. For What It's Worth I'll be talking tomorrow at OWASP London about WordPress Security and (again, independently) recommending Sucuri's scanner - it's better than Plecost, not by much, but enough.

<comment><USER7> fair enough. thanks for circling back!

Where can we see your talk/slides/etc on WordPress Security (sadly London is no longer home)

<comment><USER6> I'll upload them but I think there's enough interest to do a webex or something. I've had a few emails asking about it, so it may be worthwhile.</comment></comment></comment></comment></comment>


The Future of JavaScript MVCs - <AUTHOR> http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ <comment><USER3> We've been thinking about this a lot lately for some of the projects we've been doing for Light Table and we've essentially been doing the same thing as what David's proposing here.

What react ultimately opens up is a way to do immediate mode UI [1] on top of the DOM _efficiently_, which changes things pretty dramatically. It means we _can_ start to treat the browser as just a renderer and get the infectious design decisions of the DOM out of our programs. If nothing else, this gives us freedom, but as david is suggesting, I think this also gives us an opportunity to treat UI much more directly than we currently are. If you want to know what the state of your UI is, you just have to read linearly down through the code that produces your tree. No nest of dependencies, no state hidden in the UI components, you could even get rid of event hierarchies if you wanted.

More important than anything else, this gives us a chance to dramatically simplify our model for UI and magically be even faster than we were before. Sounds like a win to me.

[1]: [http://en.wikipedia.org/wiki/Immediate_mode](http://en.wikipedia.org/wiki/Immediate_mode)

<comment><USER4> If you want to do immediate mode, then why would you use the DOM at all? Canvas is supported in IE9+, and is much less complicated for such applications.

<comment><USER5> > much less complicated for such applications.

I'm uncertain that having to reimplement all your high-level drawing routines by hand _and_ figuring out how to handle responsive _and_ reimplementing all activation and behaviors on top of that is less complicated than just using what the DOM provides.

Even _text wrapping_ must be done by hand when you're using canvas.

<comment><USER4> I've written text wrapping and responsiveness code for canvas, in javascript - I don't think the complexity is even of the same order of magnitude as React or Angular.

<comment><USER6> What about line height? Judging by some of the responses I've seen on Stackoverflow, calculating this involves running a loop and querying the pixel colours from the canvas's buffer; a very ugly hack, if you ask me!

<comment><USER4> line height is straightforward enough, if you draw text with line height on N then you should move N pixels down for the next line.

Text baseline is the tricky part - if you want to e.g. put a taller piece of text next to a shorter one, then they should be put together so they share a baseline, but there's no decent way to get the text baseline.

The hack I use is to draw the text in a hidden span, and put a 1px inline- block span next to it, and check where the 1px span ends up. This works though it is ugly.

<comment><USER7> Why don't you precompute the space things use, including the text that is drawn using a matrix? You could easily calculate the baseline of anything by just doing matrix multiplications then.

However, I think you would still end up using a hack. The general idea of creating a replacement for the DOM has bugged me for a while too. It is a great to replace the DOM completely by a statemachine, I think. We need a New Document Model that supports "Batch Operations", is "Stateful" and uses the latest best performing algorithms published to do so.

Components are the CORRECT way, I fully agree with the facebook team here.

It seems that there is one guy who ALREADY DID all those things and replaced the DOM by something that's more akin to 2013's technology requirements. Link: [http://www.nidium.com/](http://www.nidium.com/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> There's two big highlights for me:

> Thus we don't need React operations like setState which exists to support > both efficient subtree updating as well as good Object Oriented style. > Subtree updating for Om starting from root is always lightning fast because > we're just doing reference equality checks all the way down.

I don't think anyone actually likes using explicit setters/getters in frameworks like Backbone and Ember. Of course Angular avoids it but that's by the crazy "dirty-checking". Obviously the new Object.observe will help this situation, but I love how simple Om/CLJS makes this.

> This also means that Om UIs get undo for free. You can simply snapshot any > state in memory and reinstate it whenever you like. It's memory efficient as > ClojureScript data structures work by sharing structure.

> VCR playback of UI state

I can't wait for details on this. This has gotten me really excited about client-side apps again.

<comment><USER9> >> VCR playback of UI state > I can't wait for details on this. This has gotten me really excited about client-side apps again.

Why? I'm curious what I'm missing about it and the possibilities you see?

<comment><USER8> Going beyond the normal Undo to error/state correction. A lot of JS apps right now just ask a user to refresh the page when something goes wrong. This provides an easier way to get back into a previous working state.

<comment><USER10> It gets complicated; you have to store the inverse of every API call you use in order to back it out in order to have proper Undo support. IMO the UI is the easiest part of it, as you normally just reuse methods you already use in your app.

For example:

* Rename model: inverse is to rename back to stored name

* Delete model: inverse is to create with same data

* Create model: inverse is to delete the model

* Add model to collection: inverse is to remove from collection

.. and so on. It's pretty simple. I use something similar to JS-Undo- Manager[1] to manage it. Om isn't going to get you around needing to make those calls and your UI should (generally) be able to handle executing the inverse of an action at any time.

1\. [https://github.com/ArthurClemens/Javascript-Undo- Manager](https://github.com/ArthurClemens/Javascript-Undo-Manager)

<comment><USER11> It's not pretty simple though.

In particular, if you have any triggers in your API they may need to be deferred until after undo is no longer possible, or have explicit commits. Lets say you have the ability to add a user to a group, and they will get an email about it. You accidentally add your boss to the "I hate my boss" group. How do you support undo in this case? Some sort of timeout before sending is really the only valid approach, but where?

One was is to do the deferred part on the client side, but this means closing the browser after adding somebody will mean they won't get notified at all. You really need to have support for undo in the API for this to be meaningful (or the "add to group" api returns a notification ID that you can cancel).

As an aside, I'm pretty sure the inverse of deleting a model is typically going to be _far_ more complex than just recreating it. Deleting a social network profile, for example, involves deleting all photos, associations, posts, etc. Easier just to deactivate models so you get easy undo, and periodically flush deactivated objects.

<comment><USER10> Yes, you're right; I shouldn't have put the "it's pretty simple" statement just a few sentences after "It's complicated" \- clearly, depending on the app, undo functionality can get pretty hard to manage, especially when there are emails or complicated relations involved.

</comment></comment></comment></comment></comment></comment><comment><USER12> Om looks very interesting and seems to handle exactly what I've been looking for. We have reactive widgets, which is great for making changes in the data automatically update the UI. But the hard part is closing the loop: how does the widget communicate back to the data about changes? It would be interesting if we had a zipper-like abstraction, so that the widget gets handed both its data and a function to call when it wants to change just its data. Then that function is smart enough to go find the right place in the big data structure to go do the replace.

Edit: Ok, I now see how the Om todo example is handling update, and it's really cool. It creates a set of channels that encapsulate the knowledge of how to handle each type of change to a todo [0]. That gets passed in to the todo widget as "chans" and the widget sends messages to it in its event handlers [1]. I wonder if this whole channel CRUD abstraction is general enough to make it part of Om or another layer so that it didn't have to be recreated each time.

[0] [https://github.com/swannodette/todomvc/blob/gh- pages/labs/ar...](https://github.com/swannodette/todomvc/blob/gh- pages/labs/architecture-examples/om/src/todomvc/app.cljs#L106)

[1] [https://github.com/swannodette/todomvc/blob/om/labs/architec...](https://github.com/swannodette/todomvc/blob/om/labs/architecture- examples/om/src/todomvc/item.cljs#L40)

<comment><USER13> > so that the widget gets handed both its data and a function to call when it > wants to change just its data

this is precisely how React works.

<comment><USER12> Yeah, took me a second to wrap my head around the Om todo code. I've updated my comment with links to show how it works.

</comment></comment></comment><comment><AUTHOR> I apologize that the Om TodoMVC version is a little bit buggy at the moment, I put it together mostly to demonstrate the benefits of the React/Om model and it appears I missed a couple of TodoMVC behavior issues as they weren't important for demonstrating the approach - I'll try to clean up these annoyances later this evening.

Feel free to ask any questions.

<comment><USER14> Thanks for posting this. Forgive me for not looking over your code before asking: how does Om compare with Pedestal? Am I correct in thinking there is a lot of architecture overlap, with Pedestal's application state map occupying a similar role to React's virtual DOM, and mutation through message tuples in channels?

Both frameworks seem to offer similar advantages: decoupled model and view, UI state playback (VCR style) and instrumentation. How significantly do these frameworks differ? Or are we seeing different paths towards a convergence around a new set of model/view practices?

<comment><USER15> Yes, you are right, there are overlaps. Pedestal is undergoing a major rewrite these days, as I heard from the team at the ClojureConj. Also, Brenton Ashworth, Pedestal's developer has recently started investigating reactjs and found that it "perfectly complements the new version of Pedestal" (see his Twitter [https://twitter.com/brentonashworth](https://twitter.com/brentonashworth) ) so exciting things to come!

</comment></comment></comment><comment><USER16> I know it sounds crazy, but I think your post just outlined the next 5 years of web development innovation, swannodette- This ties together a lot of ideas that are extremely important, for the first time in one place. Thanks for doing this.

I already have my own React.js+Clojurscript bridge for personal projects, because I think it's an extremely powerful web dev combination. I'm glad I can finally abandon my own library for Om!

<comment><AUTHOR> Great to hear, it needs more work :) It's more or less a conceptual foundation at this point, but I think it's going to rock with help from the community.

BTW, it was your React mailing lists posts that also really got me digging into this.

</comment></comment><comment><USER17> > Om never does any work it doesn't have to: data, views and control logic are > not tied together. If data changes we never immediately trigger a re-render > - we simply schedule a render of the data via requestAnimationFrame.

Ember.js has done this since day one with the Run Loop. Additionally it allows to coalesce operations yourself if you need control.

Angular also would not update the DOM as many times as the backbone example as it uses dirty checking to get around this problem.

<comment><AUTHOR> While it's nice that Ember.js provides a run loop that's not enough, just batching all your updates into one place just puts all of the work together, you'll still going to pay for the work and in the worse case you have to hand coalesce, yuck. In Om if there is no work ... there is no work, it's implicit in the system! No need for hand coalescing your state changes.

Angular.js still suffers as shown by the optimization article I linked to in my post. These kinds of typical optimizations can and should be pushed out of the user's hands.

<comment><USER18> You're misunderstanding. There's no hand coalescing in Ember, and there's no duplicate work. If you change your models a thousand times in a row, you still get one redraw, fully automatically.

The same holds for dependent computed properties. If you change a dependencies many times in a row, the dependent property only reevaluates once.

<comment><USER19> If that's really true for Ember.js that's great! I'm curious as to why it performs so badly? [http://www.petehunt.net/react/tastejs/benchmark.html](http://www.petehunt.net/react/tastejs/benchmark.html)

<comment><USER17> I looked at that benchmark and there's a few huge red flags right away:

1\. It's not running Ember in production mode which is much faster.

2\. It's running an older release candidate version of Ember.

3\. It is purposely wrapping individual events in run loop executions rather than just letting ember figure out when you put things into run loops.

I re-ran the benchmarks with the latest production mode Ember.js and removed the incorrect run loop usage got the following results:

[https://gist.github.com/eviltrout/8058560](https://gist.github.com/eviltrout/8058560)

It's still slower than ReactJS but much less so than before. In fact it's now #3 in that benchmark suite behind ReactJS and Backbone (and much faster than ReactJS in the completing benchmark), although I wouldn't be surprised if the other frameworks were set up as incorrectly too.

<comment><AUTHOR> Thanks for the clarifications!

</comment></comment></comment></comment></comment></comment><comment><USER20> The title of this post is strange. This seems more like the future of JavaScript views than the future of models or controllers.

I don't see a large movement to immutable data structures on the horizon in JS. I can appreciate the performance implications in Om, and would be interested in using React + Mori to the same end, but I'm not sure that it would keep me from having mutable data structures to represent most of my application state.

There are so many now-solved problems in JS MVCs that were a complete trainwreck several years ago - client-side routing, sanely managing data, and intelligently organizing your code base - that all assume mutable data structures and traditional object-oriented paradigms.

This might be the future of ClojureScript (in fact, it _should_ be the future of CLJS, as it's much more elegant than any other view solution I've seen for it), and functional data structures may be a clever way to optimize the DOM, but this certainly doesn't seem like the future of JavaScript to me.

<comment><AUTHOR> React is used by Facebook and Instagram and many others - I think these companies know a thing or two about scaling rich complex client side applications. React + immutable data has been used by Facebook to get order of magnitude performance enhancements.

So I dunno, seems like it might catch on eventually ;)

<comment><USER21> > scaling rich complex client side applications.

Instagram's really not a good example here. Do comments and likes even update in real time?

<comment><USER22> I think Instagram is not a good example too, but could you please provide the name of a project as big as Facebook (or better, 10% of it) using AngularJS?

</comment></comment></comment></comment><comment><USER23> This is like a dream coming true. I don't like Javascript's quirks, nor programming DOM with templates nor functions. I'm looking to build somewhat complex UIs without having to think in JS and manage state. React absolves me from DOM and ClojureScript keeps JS at bay.

Only if starting ClojureScript development wasn't so hard. I'd like to use browser REPL, IDE like LightTable. I am used to LiveReload's speed which makes loading changes instantaneous. But ClojureScript compiling seems to be still slow(ish) and I have already found half a dozen of different cljsbuild configuration examples. Compiling simple cljs files can take anything from sub second to 20 secs, and I don't understand why.

Could you perhaps tell more about your development process, Swannodette? How do you develop ClojureScript apps? I don't see anything beyond base cljsbuild in Om's project.clj. I confess I haven't yet had time to play with Om and see how fast it can be compiled.

<comment><AUTHOR> The first build of ClojureScript app is somewhat slow because we need boot the JVM, compile ClojureScript, and then analyze and compile your code. After the first compile it should be sub second. I always use the auto build mode and when I'm developing I don't use any optimizations. Works well enough for me.

I'd start with this, [http://swannodette.github.io/2013/10/27/the-essence-of- cloju...](http://swannodette.github.io/2013/10/27/the-essence-of- clojurescript/)

<comment><USER23> Thank you, yours is what I tried first and it's definitely fastest, sub second after first compile. However there is no REPL like cljs-start and couple of others I tested have. Between cljsbuild, Austin and LightTable I haven't yet found a stable _and_ fast solution yet. I'll try adding these various REPLS to your example and see what happens.

External browser with REPL inside LightTable seems easiest for a noob like me. Unfortunately LT doesn't support that use case yet, and you can't use Chrome debugger inside it. I still need to see what the browser thinks is happening and not just the ClojureScript's side.

I did manage to get React + JSX, CoffeeScript and ClojureScript + bREPL working with LiveReload, in a single page app. That felt truly powerful.

<comment><USER24> I hear your pain - I can't live without a REPL, and a stable browser REPL for ClojureScript development is a must.

I personally use Emacs and Austin to hook the browser REPL into nrepl. Here are some sample files that you can take a look at.

Here's a sample project.clj: [https://github.com/aamedina/foundation/blob/feature/cljs/pro...](https://github.com/aamedina/foundation/blob/feature/cljs/project.clj)

I've become a fan of Stuart Sierra's Reloaded workflow: [http://thinkrelevance.com/blog/2013/06/04/clojure- workflow-r...](http://thinkrelevance.com/blog/2013/06/04/clojure-workflow- reloaded)

Here's my dev/user.clj

[https://github.com/aamedina/foundation/blob/feature/cljs/dev...](https://github.com/aamedina/foundation/blob/feature/cljs/dev/user.clj)

Some notes about what I did here: you start the server by running (go), you can quit the CLJS repl easily by typing in :cljs/quit as normal and return to the user namespace and then safely (stop) or (reset), stop will stop the server and reset will refresh all of your Clojure namespaces (useful if you're writing macros in Clojure for use in ClojureScript).

Aside from this, just turn on cljsbuild auto with :optimizations :none, and code recompiles are sub-second.

Hope any of this helps you.

<comment><USER23> Thank you. I will definitely take a look at these over the weekend. User.clj seems particularly useful. Reloaded workflow reminds me of IPython, where you need to reload modules and reset the object instances for the new code to take effect.

</comment></comment></comment></comment></comment><comment><USER25> But I just finished rewriting everything in angular!

</comment><comment><USER26> This is really cool, and I am one of those people who rolls their eyes whenever there is another article about some newfangled way to build Javascript apps on HN.

One logical step from here is instead of having a one-to-one correspondence between the "virtual" DOM and the browser DOM is to introduce a higher level meta representation based upon the context. This seems like a logical path towards a generative, projectional approach to controlling UI and browser document rendering in general. It's been tried before in several contexts and the hacks I've tried myself have always been to hard to get my head around since it's a complex problem, but this seems like it could be a really decent foothold to build a projectional, transform-based paradigm. For example, having a meta-DOM that encodes mathematical notation (probably inspired by LaTeX), which gets transformed into the current virtual DOM, which is used to update the real DOM. User manipulates a integral on screen, and the downstream transformations are performed lazily and efficiently all the way to the screen. This type of lazy evaluation from document to screen is essentially the core challenge (from a engineering standpoint) in building a usable real- time projectional editor like that demonstrated by intentional software back in 2010 [1].

[1] [http://www.infoq.com/presentations/Intentional-Software- at-W...](http://www.infoq.com/presentations/Intentional-Software-at-Work)

<comment><USER27> That's exactly what we encourage :) composition of higher level components that render down to other high level components that eventually render to (virtual) DOM.

<comment><USER23> I wonder if this approach would work with visual XML (Docbook) and HTML editing, where resulting DOM can be complex and large. Competent writer might generate loads of input (writing 100 letters per minute, copy-paste). If my writing tool has latencies, that annoys me far more than game latency.

Other approach I have been testing is contenteditable, but this won't work with virtual DOM at all. Though how you parse an existing XML document to React's virtual DOM is beyond me. Perhaps you have to generate function calls SAX style.

<comment><USER27> We could do that probably. Would need your own parser

With content editable we can just parse he html. We have an example in the repo.

<comment><USER23> > We could do that probably. Would need your own parser

Parser for HTML and XML to generate React components and generate virtual DOM from that? This got me thinking.

> With content editable we can just parse he html. We have an example in the > repo.

It must be the weekend denseness setting in... I grepped through React repo, but I just found bits in the core that had something to do with content editable. Could you perhaps point me to right direction? If I understand this correctly, I could parse the entered HTML to virtual DOM.

<comment><USER27> Check this out: [https://github.com/facebook/react/pull/667](https://github.com/facebook/react/pull/667)

<comment><USER23> Sweet! Thank you very many. Learnt a lot today :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> I've been watching Clojure for a while, and I love the spirit of this work.

However, as a framework author, I feel obliged to point out that _of course_ you can create a more expressive and performant UI framework in a language with S-expressions, macros, and value semantics. What's hard is doing it in JavaScript. :)

It also feels a bit like reverse logic to cite ever-faster JavaScript VMs as a reason to choose a new framework for performance reasons -- shouldn't it matter _less_ exactly how you structure your application logic when you're running on a "fusion reactor"? -- but I realize there's some subtlety here about lower constants enabling better algorithms. (Still, if your framework includes a language compiler or gets to take advantage of an expressive macro system, it should be able to run on anything.)

Once it's possible to compile ClojureScript without booting up a JVM -- which could happen if it becomes self-hosting -- I'll make a Meteor package for it. I'd also like to see the compile times get a little shorter and the runtime library get a little smaller.

<comment><USER29> The main features David talks about in the post are available in vanilla JavaScript:

> If you're a JavaScript developer, I think taking a hard look at React is a > really good idea. I think in the future, coupling React with a persistent > data structure library like mori could bring JS applications all the way to > the type of flexible yet highly-tuned architecture that Om delivers.

I think there are a couple reasons Mori and other libraries like it haven't caught on in the JS mainstream:

1\. It's clunky to use them in vanilla JS compared to the default mutable objects and arrays. While you gain simpler semantics, the code becomes harder to read, and that tradeoff isn't always worth it.

2\. Most JS developers are not experienced with building programs around immutable values.

<comment><USER30> would you mind simply explaining a little more what an immutable value is? I Understand immutable as something that cannot be changed. > all of our collections are immutable How can a collection which is data that eventually ties into a db be unchangeable?

<comment><USER31> Think of strings in JavaScript. Those are already immutable:

        var fooString = "foo";
        var secondFooString = fooString;
        secondFooString;  // => "foo"

        fooString = "bar";
        secondFooString;  // => "foo"

We set the variable fooString to point to a different string, but the original, underlying string _hasn 't changed_. In JavaScript, we can think of a string as a _value_.

This is not the case with arrays in JavaScript:

        var firstArray = [1, 2, 3];
        var secondArray = firstArray;

        firstArray[0] = 100;
        firstArray;  // => [100, 2, 3]
        secondArray;  // => also [100, 2, 3]

Because we can change the underlying contents of the array, an array in JavaScript isn't a value. It's a _place_ : a reference to a location in memory. The underlying value could be changed at any time.

But, using Mori, collections are values, just like strings:

        var firstVec = m.vector(1, 2, 3);
        var secondVec = firstVec;

        firstVec = m.assoc(firstVec, 0, 100);
        firstVec;  // => [100, 2, 3]
        secondVec;  // => still [1, 2, 3]

Instead of modifying firstVec in place, mori.assoc creates a new vector that is identical to firstVec except for the change we want. We then assign the result to firstVec. secondVec is unchanged. We are unable to go in and change the underlying values because a vector is a value, not a place.

The most obvious way to build this would be to deep-copy the entire collection when it's changed, but that would of course be way too slow and wasteful — imagine copying a one-million-long array just to change one element. Clojure, ClojureScript and Mori minimize unnecessary copying using a very thoughtfully designed data structure you can read about here: [http://hypirion.com/musings/understanding-persistent- vector-...](http://hypirion.com/musings/understanding-persistent-vector-pt-1) The short story is that, surprisingly, you get "effectively O(1)" copying when you use assoc.

</comment></comment></comment></comment><comment><USER32> So I rewrote Backbone views to use a queue system that fires on requestAnimationFrame -[https://github.com/danshearmur/backbone-fast- view](https://github.com/danshearmur/backbone-fast-view)

I'm getting pretty good results with swannodette's benchmarks - [http://danshearmur.github.io/backbone-fast- view/](http://danshearmur.github.io/backbone-fast-view/)

I'm getting approx 150ms in Chrome for benchmark 1 and about 400 ms for Chrome for benchmark 2

<comment><AUTHOR> About what I'd expect for the first benchmark, but that's the kind of intervention from the user that I think frameworks should not require. The time still spent by Backbone.js on the second one more or less illustrates why I don't believe in event oriented MVCs.

</comment></comment><comment><USER33> I've been expecting this after seeing a few of your teaser tweets and as expected I absolute love it! I've been waiting for something like this ever since I read up on persistent data structures and functional reactive programming almost 10 years ago.

I'm wondering how this compare to the Javelin library as that seems to offer the same functionality when combined with hlisp. Would I be correct in saying that Om achieves the same by using ClojureScript's data structures and core.async to offload the FRP part to React?

<comment><AUTHOR> I haven't looked at Javelin enough to have a strong opinion about it. Om at the moment is completely focused on rendering EDN data and making that blazing fast. Personally I think representing UI components as generic data has a lot of legs.

I also don't really believe in templating languages, but I also think that functional boilerplate for rendering children is a bummer. I'd like to see a client side query language modeled after Datomic's Datalog syntax instead.

<comment><USER33> I'll be diving into the source code soon to figure it out, but are you then using core.async only to handle incoming user events or also to coordinate the rendering of the UI?

<comment><AUTHOR> We just use React for events that update the state of the tree. For inter- component communication core.async seems promising.

</comment></comment></comment></comment><comment><USER34> What about long GC pauses and running for cleaning up all those wonderful immutable data structures? Immutability is great when it's at the forefront of how a language is designed. Plastering immutability all over hot code paths in a language that wasn't designed with immutability in mind isn't great.

<comment><USER3> In practice, unless you're animating at 60fps over hundreds of objects (and who would do that with dom elements?), you shouldn't run into any GC issues. LightTable uses ClojureScript datastructures for pretty much everything and there were only a small handful of cases we had to optimize. Any "normal" application probably won't ever have to.

<comment><USER27> For a little more color: these objects usually live in the new generation which I've observed doesn't drop frames even on mobile.

You can pull this up on an iPhone 4S or newer (it uses the same technique with tons of allocations but doesn't really drop frames): [http://petehunt.github.io/react-touch](http://petehunt.github.io/react-touch)

<comment><USER35> Excuse my language, but holy shit that's awesome. I'm blown away by how... Native that feels, running on my 4S (iOS 7). 60fps the entire time. Jesus.

<comment><USER27> Thanks!

The secret sauce is that you can animate CSS transforms every requestAnimationFrame _without_ breaking out of React's natural data flow.

So we declaratively express the UI as a function of a single float which represents the scroll position (i.e. how open/shut the nav is or what position in the photo viewer you're at).

When we do that, we can use the excellent Zynga Scroller touch gesture physics engine (reverse engineered from iOS) to do the touch gesture stuff, then we can declaratively rotate, fade and translate everything as a function of this float.

Code is on github! And is actually in a reusable library!

<comment><USER36> Hi Pete,

I'm also super interested in this combination. However, on my new moto x, the photo scroller drops to ~45 fps and looks pretty chunky.

I also noted that you say the demos work best iPhone 5 on iOS 7, but unclear if you meant in contrast to earlier iPhones, or in contrast to Android, or both. Have you looked at all at the perf issues on Android?

<comment><USER27> Hey there --

The FPS drop on the photo scroller is likely due to jpeg decoding and painting on the main thread (I thought this was fixed in Blink but maybe not). Try "warming it up" by scrolling through all of the images a few times so the decoded jpegs get cached. I think this is the biggest perf problem on the Web today.

The reason Android may "feel" sluggish while reporting good FPS is because Android simply has a huge problem with touch event latency in the browser that you can't get around. This is where iOS really kicks Android's ass, at least on the web.

So the reason I limited to iPhone 5 and iOS 7 was because I can guarantee the touch latency and that the images fit in texture memory. Maybe they don't on the moto x.

<comment><USER37> Ditto on Firefox for Android, will try IE on WP later today. Although a solution that works on exactly 1 phone is not a solution I would ever use. To be honest, I don't get the point of reimplementing scrolling in JavaScript, can you explain why you wanted to do that?

<comment><USER27> It works well on iPhone 4S and up. And it works, but not great, on all android phones I've tried (including Firefox os on zte open!)

The point of rebuilding scrolling is to get the scroll position every frame so you can update the UI (ie rotate a photo or fade the left nav). You don't get scroll events during momentum scrolls so you have to rebuild it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> Jordan, from the React core developer team here. Awesome post, swannodette! This is exactly how we intended React to be used. As swannodette said, at Facebook, we use persistent data structures, in order to prune the update search space for comment updates. We've seen as much as a 10x improvement in update speed for certain operations.

React is a really great fit for Om, persistent data structures, and functional programming in the following ways:

1\. We want to allow developers to elegantly describe their user interface at any point in time, as a pure-as-possible function of data dependencies.

2\. We allow hooks for your system to help guide the updating process along. These hooks are not necessary. Often, we'll add optimizations long after we ship. We strongly believe that perf optimizing shouldn't get in the way of writing code elegantly and shouldn't get in the way of the creative development process and actually shipping to your users. At the same time, performance matters - a lot. So we ensure that at any point in the update process, if you know better than the framework, you can help guide the system. The fact that this is optional and doesn't change the functionality or correctness of the system is critical. Persistent data structures are an excellent (likely the very best) way to hook into the update system without making the developer do anything special.

Some people here were wondering about the apparent OO influence in React. Here's how I personally think of React's OO support/influence:

1\. It's there to help you bridge with other existing mutative, stateful libraries in your stack - you know you have them. The DOM falls into this category as well.

2\. It's there when you want to treat state as an implementation detail of a subcomponent. This is only because we don't have a good way of externalizing state changes, while simultaneously keeping the nature of them private. We just need more people to think about it (I'm sure the ClojureScript community can help us chew on this). Our internal motto is to keep things as stateless as possible.

3\. A lot of the OO support in React is there as a concession, more than being considered a virtue. It's really cool to have the FP community involved in the UI space. Those people are already sold on FP and statelessness and get the luxury of programming in tomorrow's paradigms today (how ironic that FP has been around for decades!) To accelerate this momentum, we also want to reach out to people who aren't yet sold and _change_ how they think about building UIs and software in general. The most effective way to do this is to reach out to them where they stand today, on some middle ground. It's really great to see eyes light up when they see that they can use simple functional composition in order to build large, sophisticated apps.

We're really glad to have swannodette and the ClojureScript community checking out React (github.com/facebook/react). We should consider adding some level of support for persistent data structures in the React core. Let us know if there's anything we can do to help.

<comment><USER39> Hi Jordan, ReactJS looks really awesome. Curious, what kind of persistent data-structures do you use at Facebook? Are they similar to the ones on Clojure[Script]?

<comment><USER38> We built our own immutable object utilities that prevent mutating anything in the object graph. These immutable objects look and feel just like regular objects/arrays, so you can use functional map/reduce etc. The only thing you can do with them besides reading their properties, is to create a new version of the previous object with changes applied. We then use object identity to detect when things could not have possibly changed between render cycles. We prune off those paths that will not need to be updated, justifying the pruning based on dependent data's object identity remaining the same over time. Same object identity across two points in time necessarily implies that their deeply immutable data structures have not changed, therefore their generated output could not have possibly changed.

<comment><USER40> Would it be possible to maybe show an example of using Mori or similar with react?

</comment></comment></comment></comment><comment><USER41> There was a really good talk from Charles Nutter about making JRuby fast and the mutable things that Ruby does that basically break caching and things that you do to make things faster at runtime.

I'm not surprised that persistent data structures can make things fast, in fact I've spent the last week speeding up a Rails app in some ugly spots by preloading the data structures to keep DB queries from happening, effectively turning a lot of just in time queries at the ORM level into a pre-loaded data graph. The speed is fantastic, but what is interesting is you could add a level of immutability to this and would be potentially even faster, especially on top of the JVM.

I've been playing with the idea of immutable entities in Obvious Architecture for a while and it really changes the way you look at your business logic and performance.

</comment><comment><USER42> I spent the day working out the React tutorial in Om. It was an enlightening process.

Code: [https://github.com/jalehman/react-tutorial- om](https://github.com/jalehman/react-tutorial-om)

</comment><comment><USER43> This kind of thing is exactly what makes me think CLJS is the current frontrunner to be the first compile-to-JS language to gain mass adoption without JS-like semantics (as CoffeeScript has).

It's the performance.

So many of us who want JS alternatives have made our peace with the idea that we'll have to sacrifice a bit of performance if we want to use a nice language.

But being able to _improve_ performance while using a nicer one?!

Count me in! I already have a serious project in mind for this.

<comment><USER44> For me, the non-idiomatic compiled JavaScript and Google's library that's stopping me. Wisp seems like a good solution with it being a Clojure dialect that provides super clean JavaScript that you can work with.

</comment></comment><comment><USER45> On another note: maybe if the installation of ClojureScript would be manageable in, say, an hours instead of having to search half a day among outdated information, more people would try it (and this is from someone who already uses Clojure and Leiningen a bit).

Clojure and its libraries has the worst documentation, and this malpractice seems to be continued in ClojureScript.

<comment><USER46> [https://github.com/magomimmo/modern- cljs](https://github.com/magomimmo/modern-cljs) is how I got started with Cljs. If you scroll down, you'll see some tutorials that get you set up and lead you to a workflow.

[http://swannodette.github.io/2013/10/27/the-essence-of- cloju...](http://swannodette.github.io/2013/10/27/the-essence-of- clojurescript/)

</comment></comment><comment><USER47> This is fantastic. I've been goofing around trying to figure out a way to approach the general case (representing an interactive DOM with just EDN), but I hadn't done jack on performance. Thank you thank you David.

</comment><comment><USER48> Not to take away from the other points in your post, but on the benchmarks, the backbone example is writing to localStorage, while the om example isn't.

The overhead from localStorage appears to account for a significant chunk of the difference in performance. You can remove the localStorage calls with 'Backbone.sync = $.noop' or similar. After doing that and clearing localStorage, benchmark one drops to around 350ms, and benchmark 2 drops to around 2000ms.

Of course, benchmark 2 is where your library really shines, and backbone still takes its time with that one.

<comment><AUTHOR> Not true, all Om timing information includes writing to localStorage. I just don't load the page from localStorage because that made benchmarking tedious for me.

<comment><USER48> My mistake - i see that now. I think I lost sight of the single key for your example in with the hundreds of distinct keys from the backbone one.

</comment></comment></comment><comment><USER49> I'm really excited about this. Until now I've hated working with Javascript because of a combination of the language itself, and its primary domain (the DOM).

Seeing React.js at JSConf.asia last month got me excited that I don't have to touch the DOM anymore, but I still had to deal with Javascript the language itself.

And now this comes along. Now I don't have to deal with DOM (or at least it offers better abstractions for working with it) _and_ I get to use the most pleasant language I've tried so far.

Christmas came early. :)

</comment><comment><USER10> I'm not great at reading ClojureScript - but I'd really like to port some of the optimizations from Om, such as the rendering on _requestAnimationFrame_ and usage of _shouldComponentUpdate_ to Backbone.LayoutManager[1]. Swannodette, if you're around, do you have a minute to give a more in-depth explanation of how that works?

1\. [https://github.com/tbranyen/backbone.layoutmanager/wiki](https://github.com/tbranyen/backbone.layoutmanager/wiki)

<comment><AUTHOR> If you're using Backbone.js I would just rely on React to deliver the requestAnimationFrame enhancement. As far as shouldComponentUpdate, just make your component implement a better one.

To be honest at this point there is little that Om does over React other than provide really good defaults ;)

<comment><USER10> Thanks for the input. I'll look into it. We've been talking a bit about doing a more general rewrite of LM and I've been looking for ideas that would make it worthwhile (not just cleaner code, but better perf or features). This might be one of them.

</comment></comment></comment><comment><USER50> How is this different from the dirty checking that Angular does in its ModelView update cycle?

<comment><USER51> React does the diffing on the output (which is a known serializable format, DOM attributes). This means that the source data can be of any format. It can be immutable data structures and state inside of closures.

The Angular model doesn't preserve referential transparency and therefore is inherently mutable. You mutate the existing model to track changes. What if your data source is immutable data or a new data structure every time (such as a JSON response)?

Dirty checking and Object.observe does not work on closure scope state.

These two things are very limiting to functional patterns obviously.

Additionally, when your model complexity grows, it becomes increasingly expensive to do dirty tracking. However, if you only do diffing on the visual tree, like React, then it doesn't grow as much since the amount of data you're able to show on the screen at any given point is limited by UIs. Pete's link above covers more of the pref benefits.

<comment><USER52> So, maybe i'm misunderstanding, but, the perf advantage is that react waits until the next RAF and then only updates the parts of the DOM that actually changed? So, now i'm wondering: why can't the browser do that? Isn't this whole middle-man approach something to eventually be optimized out?

<comment><USER53> Sure, the browser could implement a virtual dom and then sync it and do a reflow once per frame.

<comment><USER54> You can do that with the help of `document.createDocumentFragment()`.

</comment></comment></comment></comment></comment><comment><USER55> Been playing around with RxJs and wonder how much difficulty would it be to combine React with this? RxJs seems to work particularly well with Angular but I know Back one much better. is there harmony between the two?

<comment><USER56> I think it really depends on what you are trying to accomplish. For one thing, a quick peak into React revealed to me that there isn't two-way data binding. I think React and Angular have a lot of friction. They both seem to do well with data binding in their respective ecosystems.

<comment><USER27> Our (React core) team has experimented with React+RxJS before: [https://github.com/facebook/react- page/commit/082a049d2a13b1...](https://github.com/facebook/react- page/commit/082a049d2a13b14199a13394dfb1cb8362c0768a)

We think that "two-way binding" is actually very, very hard to get right since it flies in the face of the way data flows in a von Neumann program.

Instead, we provide some sugar that lets you get the conciseness of two-way binding but without making it hard to debug or understand performance: [http://facebook.github.io/react/docs/two-way-binding- helpers...](http://facebook.github.io/react/docs/two-way-binding-helpers.html)

But we don't really recommend that for newbies since it's important to understand how the data flows in your program before covering it up with sugar.

</comment></comment></comment><comment><USER57> Lol, why can't it be just another FW that's not MVC? We can't evolve? Games don't use MVC, they use E/S. There is more than that pattern. Also when using API, you need something better.

<comment><USER58> What's E/S?

<comment><USER59> I'm guessing he means [http://en.wikipedia.org/wiki/Entity_component_system](http://en.wikipedia.org/wiki/Entity_component_system)

While some big games have used it, a lot more games are still stuck on class hierarchies.

<comment><USER60> Those aren't orthogonal. There's a pretty wide design space for component systems. Lots of games use "components", where game entities are split into pieces for different game domains (rendering, AI, etc) without going all the way down the entities/components/systems path.

It is true that most games don't use MVC. I think that's because MVC isn't a good fit _for games_. It seems to work fine for business apps, though more experimentation is always good.

<comment><USER27> I think swannodette's post is less about MVC and more about declarative manipulation of the DOM. As long as you have a function somewhere that creates that representation and a way of handling events you can use any sort of architecture you want.

</comment></comment></comment></comment></comment><comment><USER61> Is there any reason we couldn't mod the JQuery object to work on a virtual HTML tree that syncs with the DOM on requestAnimationFrame?

Couldn't this even be done at the browser level?

I think I must be missing something.

<comment><USER16> That wouldn't change the amount of DOM thrashing caused by jQuery, it would only improve rendering (and perhaps reflow) performance, but would not improve the cost of DOM manipulation.

<comment><USER61> Can you expand on that a bit? As I understand it, om/react don't improve the cost of DOM manipulation, they just reduce the amount of DOM manipulation that's done by only altering parts of the DOM that have changed. Couldn't you do the same type of change checking on the virtual DOM tree so that you only touch the actual DOM when it changes?

<comment><USER16> I see, yes viewed that way you COULD do this with jQuery- But you'd be missing most of the benefits of react.js, due to the missing "functional programming" that is possible with the react.js approach.

</comment></comment></comment></comment><comment><USER62> The flame graphs are meaningless and misleading: om's graph is only looking at 260ms of data, while the backbone's is looking at 1200ms.

<comment><USER10> But that's the whole point; it's effectively the same operation, but Om takes 1/5 the time and takes a much more efficient path. Backbone with some simple RequestAnimationFrame deferral somewhat approaches that speed but in some cases Om still beats it by an order of magnitude.

<comment><USER62> gotcha. understood.

</comment></comment></comment><comment><USER63> Neat, first time I've seen Computer Modern outside of a TeX'd pdf. It looks quite nice on your site.

Also... an interesting read, thank you :)

</comment><comment><USER64> AngularJS

</comment><comment><USER65> It may be because I'm not familiar with ClojureScript's syntax, but the whole sample application code seems like a real mess to me. It's full of boilerplate code and it is happily mixing application logic with DOM rendering. [1]

Compare this with an alternative JS MVC framework (like, say, Knockout.js) and another modern "javascript-compatible" language (like, say, TypeScript), and see for yourself. [2]

While I didn't run any benchmarks, it's safe to assume the Om demo is faster. However which sample do you think is easier to write, test and maintain? If "The Future of JavaScript MVC Frameworks" is supposed to look like the Om sample, sorry but I'll pass.

[1]: [https://github.com/swannodette/todomvc/tree/gh- pages/labs/ar...](https://github.com/swannodette/todomvc/tree/gh- pages/labs/architecture-examples/om/src/todomvc)

[2]: [https://github.com/jpatte/TodoMvc- Knockout.ts](https://github.com/jpatte/TodoMvc-Knockout.ts)

<comment><USER66> I don't see how language has anything to do with you criticism.

<comment><USER65> It's not really about a choice of language.

My point is that if Om claims to be superior to other JS MVC frameworks - <USER2> it is presented as "the future of MVC frameworks" \- it needs to be good (if not superior) in many aspects. Performance is a big deal all right, but another aspect (which seems essential to me) is that using this framework should be easy, concise and intuitive. And I've been kinda disappointed to see that the sample code given to present Om in action is not. At all. If I wanted to fiddle a bit with this code right now, to add a few features for example (like adding a timestamp besides each item indicating when it was created), I wouldn't have any clue where to start.

What bothers me is that Om has clearly been written with ClojureScript in mind, so in a way this framework is supposed to be sublimated by the language. It should "feel" right. And I know it's possible with other frameworks (and my comparison with Knockout+TypeScript was meant to illustrate that), so I expected it to be the case with Om.

<comment><USER29> This sounds like a case of simple, not easy: [http://www.infoq.com/presentations/Simple-Made- Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

You could add a timestamp to each todo with two changes:

[https://github.com/swannodette/todomvc/blob/gh- pages/labs/ar...](https://github.com/swannodette/todomvc/blob/gh- pages/labs/architecture-examples/om/src/todomvc/app.cljs#L101)

        (defn handle-new-todo-keydown [e {:keys [todos] :as app} owner]
        ...
                (om/update! app [:todos] conj
                  {:id (guid) :title (.-value new-field)
                   :created-at (js/Date.)  ;; <-- add this line
                   :completed false :order (count todos)})
        ...)

[https://github.com/swannodette/todomvc/blob/gh- pages/labs/ar...](https://github.com/swannodette/todomvc/blob/gh- pages/labs/architecture-examples/om/src/todomvc/item.cljs#L48)

        (defn todo-item [{:keys [id title editing completed] :as todo} {:keys [comm]}]
        ...
                    ;; change this line
                    (dom/label #js {:onDoubleClick #(handle-edit % todo m)} (str
        (:title todo) (:created-at todo)))
        ...)</comment></comment></comment></comment>


Ask HN: How Will "Web Assembly" Succeed Where "Adobe Flash" Failed? - <AUTHOR> From what I've read [1], Flash was initially accepted, but then gradually hated more as [2] problems became obvious.<p>Could the same be true for the adoption of "Web Assembly"? Besides using the Javascript runtime and sandboxing, they seem like they may have similar problems in the future like; running binaries, compatibility, security updates... just like Flash did... but maybe this time it's different...<p>[1] https://thehistoryoftheweb.com/the-story-of-flash/<p>[2] https://www.granneman.com/webdev/graphicsmultimedia/multimedia/flash/whatswrongwithflash <comment><USER2> Steve Jobs hated Flash because it was buggy and Adobe was slow to fix the constant problems. Additionally, it was resource-intensive and slowed down the new Macs.

Once he started to advocate for its replacement with something else then that was the beginning of the end. Flash was mostly a pain since you had to install it up to the time when chrome started to include it as part of the browser.

I initially hated it because web designers decided to use it to produce stupid and time-wasting opening screens to websites.

Web Assembly is a different story. It's native and browser makers will be quick to fix any problems. Plus its main purpose is to speed things up. I think it has a future but only time will tell.

<comment><USER3> I think browsers are buggy too. Leave a javascript intensive page up for a while and look at your memory. Instead of bitching at adobe now people will bitch at google. I just feel memory management for JavaScript just isn't that great. After a while you have to close the page and restart it.

It just seems everything is cyclical in tech. Microsoft gets monopoly on browser market. People complain about it. Flash gets monopoly on streaming media people complain about it. Now Chrome has a monopoly on the browser market.

</comment></comment><comment><USER4> Browsers need to get their s##t together, webrtc / video-audio is still a mess to work with and they hog the cpu in a way that flash doesn't (anymore). There is not even a standard stack to replace the adobe flash/media server stack.

</comment><comment><USER5> 1\. Web assembly has (better) access to the DOM, making it easier to integrate with other web content.

2\. With WASM, browser makers are in control of the engine, so they can't complain/can only complain internally if said engine is slow, buggy, or insecure.

</comment><comment><USER6> HTML5 and the success of the mobile form factor (ok fine, the iPhone) killed Flash. If those two technologies didn't succeed or exist, I'm sure we would still be making due with it where it excelled.

<comment><USER7> The success of mobiles or the iphone themself had no impact on the death of Flash. Apple's blatant hatred for it and decision to publicly vilify it and discriminate against it did.

There were plenty of phones that supported Flash, at least initially. Adobe could have done better to keep it going but I think they saw the writing on the wall early on.

<comment><USER8> They released Flex at about the time all that happened - so many there was some belief in the future of "Flash"?</comment></comment></comment>


Ask HN: Are there any good tech or science related audio books? - <AUTHOR> I will be making a 10 hour drive by myself in a few weeks. I've never listened to an audio book before but am thinking this might be a good opportunity to give one (or two?) a try.<p>Are there any good technology or science related audio books that folks could recommend?  I'd be interested in anything from software development to machine learning to mathematics to cosmology. Thanks! <comment><USER2> This comment might not be useful.

Are you looking for popular science variety? I ask because the topics you mentioned are best looked at, read in bits, and worked on in order to be understood. I can't fathom learning any of these by listening alone. I might pick up the jargon but nothing more useful. I would rather pick a humanities topic to listen to to keep the mind active, fresh and compensate for the tech fatigue which will eventually happen to us.

Alternatively, or if you insist, you could download and watch some OCW/MOOC lectures on these topics which can be a nice middle ground.

</comment><comment><USER3> Try podcasts too!

General science an engineering, very detailed and excellent e.g. a recent episode covered superconductors and their use in particle accelerators [http://omegataupodcast.net/](http://omegataupodcast.net/)

Data Science and Machine Learning [http://lineardigressions.com/](http://lineardigressions.com/)

Embedded SW dev and related topics [https://www.embedded.fm/](https://www.embedded.fm/)

</comment><comment><USER4> In the fiction realm, Yoon Ha Lee's Ninefox Gambit is a fascinating math/geometry based sci-fi novel.

</comment><comment><USER5> I enjoyed Blood, Sweat and Pixels audiobook which looks behind the scenes of video game development for multiple games.

</comment><comment><USER6> couple of recommendations: Bill Bryson's A Brief History of Nearly Everything Neil Degrasse Tyson reading his own book, Astrophysics for People in a Hurry Pale Blue Dot: A Vision of the Human Future in Space - By Carl Sagan Chaos by James Gleick</comment>


Forklifts, Rip and Replace, and Other IT Fairy Tales - <AUTHOR> http://devcentral.f5.com/weblogs/macvittie/archive/2009/06/26/forklifts-rip-and-replace-and-other-it-fairy-tales.aspx

<comment><USER2> And there was I thinking it was just me. I have just sat down to write some .NET framework code to access COBOL indexed sequential files so that an existing web based application can access a "New" package that will be installed over the next couple of months.</comment>