Locutus will largely have the same mission:
Offer a community platform to collaborate on JavaScript counterparts to functions from other languages, for fun and educational purposes.
Locutus will, however, also be different on a few key points. Locutus will focus on:
var strings = require('golang/strings')
and, in case the browser is your target platform, bundle this via Browserify, rollup.js or webpack.note
. An example of this would be opening a file from disk. We would then state it is Node.js-only.While it is still very much a work in progress, I have already deprecated and updated many functions that did not adhere to this renewed focus. If you spot a function I overlooked, please let me know on GitHub.
I feel these changes were needed to regain the motivation required for leading this project. For a long time, I have struggled with php.js in its old form. I rarely did maintenance runs anymore and when I did, it was guilt-driven rather than out of curiosity or excitement - the things that led me to start this project.
There are several reasons why I had lost my intrinsic motivation:
Knowing that I was beginning to fall short as a project lead, I tried to recruit fresh blood to replace me. However, even though there is still an active community of contributors, I couldn’t find any volunteers for taking the lead. For a while, I considered declaring [UNMAINTAINED]
, but I felt - and still feel - too great a deal of duty and responsibility towards past and present contributors.
So instead, I started thinking about what it would take for me to get my mojo back. Having analyzed what had crippled it over the past 9 years, I decided to make the changes that would allow it to flow back again.
If you are interested in the nuts and bolts, these are a few things I have been secretly working on in order to clean up our codebase and breathe new life into this project. I have:
$global
that works in both Browsers and Node.js (we should try to avoid this when we can though)eval
, new Function
and other bad practicesrequire
npm install
ed_workbench
and _experimental
folders. They are available for reference in 1.3.2, but making them harder to find for newcomers should help avoid complaints and confusion. If you want to experiment, we can use local files or branches when it’s time to collaborate.I understand this all can feel like a radical shift, since functions have different locations and there is talk of deprecating functions. Perhaps you wrote these functions with your own blood, sweat and tears. To make matters worse, I will also be deprecating many GitHub Issues and Pull Requests that have become invalid due to this new major push.
I hope you can agree that this project found itself in a dead-end street and that I had to undo some of our work to back out and get us on the road again. I am doing this not to hurt past contributors, but to honor them. I have spent many nights and weekends modernizing this project, so that our work could be given new life. I would also like to voice a word of appreciation to you as a contributor, for the hard work that went into crafting this project. Rewriting a language in another language is no small task, and people tend to forget that in order to port an alien language to JavaScript, we had to write a lot of JavaScript.
In failing to restrain myself and having tried to port the entire language, I may have ventured into the darker engineering arts. And in the end, it did not even let me fully realize my goal in return. I accept defeat here. However, I am also proud that we have built a welcoming and friendly community together where over the course of 9 years, hundreds of developers from all over the world have helped each other to improve their code, to learn JavaScript, and help others learn it. I, for one, have become much more familiar with JavaScript’s delicacies because of it, and I like to think the same goes for many of you as well. Therefore, I accept both defeat and victory.
As a contributor to this project, I hope Locutus brings the changes that can spark your interest again, just as it has for me. I hope you will join me on this new adventure to a magical land of standard libraries full of functions that are just screaming to be ported. I am looking at you, rainy Sunday afternoon..
This time we will be a little bit older, a little bit wiser, and hopefully have the resolve to steer clear of the darker areas. Nevertheless, we will have just as much fun in challenging ourselves and each other, as well as by learning other languages. I promise! : )
For those that can forgive me for my past mistakes and for deprecating some of our previous work in this new major release: you can try Locutus right now if you want:
|
|
|
If you want to help Locutus, our newly added languages don’t have much meat on the bones yet and it would be fantastic to see if you can think of ways to assimilate a function that Locutus currently does not harbor.
Also, there are plenty project-wide ideas in our Backlog that we would love help with, so I guess there is just one thing left to say..
]]>I’m planning to push out a big release soon that will change a lot of things about this project.
Among things, it will:
var sprintf = require('string/sprintf')
(and use Browserify, Rollup, or Webpack on that if the browser is your target)The old version will remain available as v1.3.2
.
I certainly hope you are not using this project like so:
https://raw.githubusercontent.com/kvz/phpjs/master/functions/strings/sprintf.js
as that is asking for BC breakage as well as impolite towards GitHub, but if you are, you should change your links to
https://raw.githubusercontent.com/locutusjs/locutus/v1.3.2/functions/strings/sprintf.js
until you can figure out how to vendor in that function and host it yourself.
If you are using the project via npm, the old version will be available under the 1.3.2
package version.
If you are using it via Git, use git checkout v1.3.2
.
The new version will be available as v2.0.2
, as well as master
by the time I launch. I’m not sure yet when that will be, but I thought it might save some headaches to already give the heads up about this.
Stay tuned for more,
]]>Four years ago we switched from a PHP generated site to one built in Octopress, so it would be easier for people to contribute, and we would not have to worry about keeping servers online.
Things have changed since then. The Octopress version we used is no longer supported, and the new 3.0 is leans heavily on Jekyll.
With the backing of GitHub for GitHub Pages, Jekyll itself has improved tremendously.
Combined, I felt we reached the tipping point where it made more sense to port things to Jekyll so we can profit from their speed of development, ecosystem, and the fact that many developers are already familiar with it.
Long story short, I just completed the migration, and if you want to work on the website, here’s what you’d do.
Jekyll runs on Ruby, so make sure you have that installed, preferably with a working version of bundler. The rest of the site-building dependencies are node-based, so make sure you have a working npm
as well.
To install the dependencies:
|
To start a local version of the website and open a browser that will auto-refresh on changes, type:
|
Now hack on the files in the ./website
folder, until you’re happy with the local results. Commit the changes to Git or send in a PR if you don’t have write access to the repository. This means the sources are saved, but someone with write access still needs to deploy.
To do that, type:
|
That’s it : )
P.S. We have a few custom build steps such as rendering the functions, that make it hard for us to only use the GitHub Pages provided Jekyll, this means for the time being we’ll be relying on our own scripts and Jekyll version. That said, it’s still possible to orchestrate auto-deploys whenever there’s a change to master
, by using Travis CI and encrypted environment keys. If I have time, I’d like to set this up too. This way people could propose changes, and merging them would be enough to see them go live.
Best wishes,
]]>The reasoning behind adopting such a widely supported coding style, has not changed. Locutus should be focused on its added value, and less so arguing about, and inventing custom conventions around coding style.
What has changed a great deal though, is the JavaScript landscape. A large part of the community is gathering behind Feross Aboukhadijeh’s JavaScript Standard Style and ESLint.
Standard offers sensible defaults (no semicolons might take some getting used to but it’s really ok and after two weeks you won’t look back). ESLint offers powerful ways to enforce the standard.
ESLint for instance, offers a --fix
command-line argument flag, that converts non-conforming codebases to whichever coding style convention was selected.
The auto-fixing does not cover all rules yet, but it’s getting better every month. As we upgrade these modules and fix our codebase, more and more legacy will conform.
Additionally, I’ve added non-fatal linting to our Travis CI builds, so you can see which functions don’t comply, and make them.
Locutus does few naughty tricks to bend the laws of physics and overcome a few obstacles in porting programming languages. For this reason, Locutus a few exceptions listed in .eslintrc
. As a goal for the future, it would be interesting to see if we could lose these exceptions.
Best wishes,
]]>In this light, I’ve decided to adopt Felix’ Node.js Style Guide for coding standards, instead of running our own.
It saves us time maintaining and it becomes easier for people to contribute because they don’t have to memorize where Locutus diverges.
For the big parts our codebase is already compatible with it, so we won’t get any weird space + tab indentations as a result, as we start adding code that follows the guide.
Going forward, contributions should comply with these conventions before being merged in.
Best wishes,
]]>The new site has no server-side code. Instead we generate HTML using Octopress and push to GitHub Pages, all from one repository.
This saves hosting costs/overhead and makes it really easy for people to submit pull requests and for contributors to make changes that I don’t always have time for. It makes the project less dependent on me and more a community effort.
To move forward, sometimes you have to cut features. In this case I had to lose our compiler, a webtool that relied on server-side code to generate minified packages from php.js functions.
Understandibly this has raised questions. It is still possible to bundle 4 useful functions:
|
but some people think php.js should bundle all of it’s functions into one big file:
Not providing an all-in-one, downloadable, minified, ready-to-use .js file is going to kill php.js. You’ve abandoned windows users, and really any non-CLI junkie. While I am capable of compiling this myself, what a headache. You’ve introduced a barrier-to-entry that didn’t exist before, and by not existing, allowed for the following you now have. I highly suggest that you have this available for download, either here or on github, such that you can keep (and maintain) the momentum you worked so hard for.
I’d like to comment on that here. While I appreciate the sentiment, wether the project is being killed by these changes depends on how you look at php.js. To me, php.js is a resource:
This is what I feel php.js should focus on. Making functions. Making them better.
If - on the other hand - you think of php.js as a
..then yes, these changes are going to kill php.js.
I have limited time to spend on open source, and I want to spend it on things I enjoy and can believe in. Not on working to support use-cases that keep new developers from learning, or make the web slower. I’m sorry if this upsets folks but it really is my free time.
Luckily though for people with different views, I released php.js under MIT so it’s cool for anybody to fork this project and run with it.
If anything, knowing that the php.js repository will focus on the raw ./functions
makes this easier.
Best wishes,
]]>Welcome to our new site. The old one had a lot of dead weight that nobody used and was basically unmaintained.
This one is generated by Octopress as plain html, and then stored on Github pages.
The source to do that is inside the Locutus directory in the _octopress
dir,
and freely available.
For instance, you can now very easily:
Next, any Locutus contributor
who has Octopress set up
(this mostly involves having the right ruby & gem versions) can then run
make site MSG="describe what you did"
in the
project’s root dir to deploy the changes.
This should make it easy for Locutus contributors (or any Github user really, using pull requests) to update the site, making it less dependent on few core members, and more a community effort.
This is also the way I want to do regular Locutus development. Less via comments, more via the power of Github.
To people wondering where the compiler has gone to, I’m discontinuing that feature. It was more often broken then working, and I think this site should focus on being a simple resource and discussion platform, and not much else.
Now that everything is open sourced more I think there’s room for anyone to build a better alternative.
While I’m not actively involved with Locutus anymore, I hope taking this step will make the project ready for the future.
Best wishes,
]]>