Is this still being maintained? Does it need maintenance? #390
Comments
|
+1 |
|
I believe the clear answer is no, it isn't being maintained |
|
Hrmm. Anyone keen to take over maintenance, I'm happy to make this commonjs compliant and do other improvements providing we can get some funding behind it. For some background on how History.js has been maintained over the years, see: http://stackoverflow.com/a/17394242/130638 |
|
If this is not being maintained, is there any viable production alternative still being maintained at the moment or is it the only lib that allows the use of history without all the browser quirks ? |
|
@istrasoft Backbone's router and history objects are very modular, lightweight, have decent browser support, and fully support amd, commonjs, and window globals for module options https://github.com/jashkenas/backbone/blob/master/backbone.js#L1280-L1379 https://github.com/jashkenas/backbone/blob/master/backbone.js#L1381-L1640 |
|
I should add that backbone and most alternatives provide their own APIs. History.js is different in that it's a polyfill, where it fixes/shims the html history and push state standards. Personally I like polyfills more but I find History.js has too many issues at the moment due to lacking maintenance. @balupton regarding the part you mentioned in your post: "pushState call instantly triggering the statechange event" does this deviate from the w3c spec, or is the spec vague in this area? What do you consider the philosophy of history.js to be? Is it intended to shim the history/push state support to be as close to the standard as possible? |
|
@mreinstein indeed Backbone is interesting, but including it plus underscore just to implement a cross browser ajax navigation with history is a bit overkill isn't it ... @balupton Is the company which took over the copyright to history.js planning to maintain it, or just list it on their projects page ? |
Here is the main source file for history.js: Here is all the source code for underscore: Even with Backbone.Router + Backbone.History + underscore, it's still smaller than just the main source code file for history.js alone. that being said, Backbone.History is only using about 6 functions from underscore. It could be significantly slimmed down. Backbone also supports lodash, which has more modular builds than underscore. |
|
Ok thanks @mreinstein. Now since you pointed this out the next question is : why is history.js so huge (even if json2 and html4 are excluded)... and does it need to be ? |
|
I did a very quick glance at the source in history.js, and there are certainly parts that could be removed. I found a few hundred lines of debug related code for example. Another source of increased length is the commenting and whitespace uses a format that is more verbose. That definitely pads it out a lot. I'm definitely willing to attempt a cleanup, if @balupton is amenable to it. One thing that would be super helpful would be to catalog all of the bugs that history.js works around. IMO that's the library's biggest value at the moment. I would take all those bug workarounds that history.js has, compare them to what backbone.history and backbone.router do, build up a test suite to cover all those cases.. and then attempt a refactor. I'd probably do something like history2.js |
|
another thing I'd do is add UMD support and rip out all the dojo/ext/jquery/mootools adapter stuff. I don't think they are needed, and if they are they should be separate modules. I'd prefer history.js to do one thing; provide a native shim of history/push state. Tiny modules that do one thing well. |
|
Wonderful. If I'm not mistaken though, history is more of a higher level api to HTML5 history than a routing system with a finite preconfigured number of routes, which is the answer to a different need, right ? Me for example I would need a dynamic routing system where the URL of the page fragment retrieved via ajax would be constructed dynamically from the requested full page url, so not just simple fragments /home, /page1, and so on ... |
I think that's correct, but I don't think that's what history.js should be. I'd prefer it to stick to it's original intent of shimming the history/push state APIs.
I think that would be a good module to write based on the history api. In fact I think that's what Backbone.Router and Backbone.History basically do. |
|
Yes it does, for nice beautiful urls... I'm maintaining an app with legacy urls with lots of arguments and values, so it would not work.. |
I'm not sure what "it" refers to in the previous comment. If you have an app with legacy urls and lots of arguments and values, then you write a small module that handles all of them. That's application specific business logic. |
|
"it" meaning the dynamic routes in Backbone.router. |
|
Ah ok, understood. If I had my way, the dynamic routing you are talking about would be out of scope for history.js. Though it could be built as a module that relies on history.js. |
|
Exactly. What I and other just wish for, is that a complete abstraction to pushstate/popstate that I can include in the page, and that would just work cross browser. No other fancy shmancy stuff, no zillions of kilobytes of code. I for example would be willing to sacrifice the ability to save any data with states if it would cut the size and complexity of the shim significantly. Also, maybe make the decison not to support IE<9 (like jQuery 2 or Foundation 5) and Safari < 6... |
|
Reading the code of Backbone.History compared to History.js it appears that in case you don't care about older browsers that don't at least support hashchange event, Backbone.History actually has everything one needs to use statechange or hashchange, as most of the bugs fixed in History.js do belong to older browsers... |
Bevry is my company. We created it. It goes on our project page. We don't have any projects that actively use it, so we don't maintain it actively. When we have projects that use it, and find a bug, we fix it. From our sporadic use, History.js works well. There seems to be a few definitions of maintenance being thrown around here. Maintenance is solving your own issues. Support is solving the issues of others. A project as diverse as History.js can only work well if the people actively using it maintain it, whomever that may be. As supporting History.js, due to it's popularity, is a sure way to burn out. If we could raise a boatload of money, maybe we can support it. I've actually considered crowdfunding a fair few times, however living in Australia makes it very hard for us to receive crowd funding money.
It's not just about older browsers, but different browser implementations: If you don't care about different browsers doing their own thing, then use the native API. If you care about consistency, use History.js |
|
Thanks for the clarification @balupton. |
|
Not sure. My last content edits were 3 years ago. Someone could certainly check. What we really need is a acid test for the html5 history API so a table like that can be generated automatically. I attempted writing one when I did that table, but not one browser worked correctly. Perhaps it's worth another shot. Getting our test suite completely automated would also make merging things way easier, as so far, humans must run our automated test suite manually in different browsers and environments and do a few tests manually too. |
|
As a side comment, it's something that annoys me very much as a developer is to have APIs (XMLHttpRequest, History, loads of others) that are made in a way that it's practically unusable by itself and need a huge lib to sit on top of it all to make it practical and consistent. What is quite worrisome is that it does not change with time. I mean, the spec/api makers know it was how it worked before, but the new APIs are released with the same old issue... |
@balupton that is disappointing. This is the most widely publicized polyfill for the history api. The state of history.js has ramifications beyond whatever Bevry, inc. uses it for.
There are other open source projects that don't raise a boatload of money and still are very actively maintained. Look at webshims for example, or any of substack's projects. Not exactly cash cows for their maintainers but they are alive and well.
Sounds good, I'd like to help with this to start. Do we have tests now for these? I've seen the browser bugs that history.js handles listed in human readable form in several places:
Is there some overlap of the above lists with the existing test suite here? https://github.com/browserstate/history.js/blob/master/tests/tests.js |
|
maybe we could use https://ci.testling.com for our cross browser automated test suite. I'd be willing to set this up, but I'd need some help with constructing the tests. |
|
Also, a re-check of the current status of browsers would be nice. A lot of frameworks and libs drop older browsers, so it would probably simplify history.js to do so too (ie who uses IE6 or safari 4 any more) ... |
|
@balupton Regarding API standards, why does History fire the statechange event handler as soon as History.pushState is called programmatically, while the API states that popstate event should not be fired upon call to pushState ? Any plans to do something about it maybe, given the extra long and old thread of comments ? #96 |
|
@istrasoft I believe that in a beta build I was working on before I handed it over to @andreasbernhard I had caused the separation. It was initially done as best practice that I had used in all my applications, however considering the noise it generated, any potential benefit of it is drowned by the noise — which may or may not be without its great reasons too. @mreinstein substack's projects are maintained by people actively using them, rather than people supporting them who aren't actively using them. There are plenty of projects that substack and tj no longer maintain, but the community of people using them, maintain them. For what it's worth, this desire of maintenance over support, certainly may be disappointing to the consumer, however open-source consumerism is a force that steals away the souls of good hearted maintainers and eventually drives them to insanity. Originally, I did support History.js by myself, but it is too much for any single person to maintain individually, they can try, but at the end of the day, if they accept more than they can, and more then they are able to, and more than they are interested in, they will burn out. Just because a person made an open-source project, and it has value to many people, doesn't mean that person is now enslaved into eternal support of it, having the project own them, and control their lives. There is a good discussion about this going on here isaacs/github#167 about how project creators are struggling with the pressures and their coping techniques. |
I am not suggesting that every project those people have created are 100% maintained and kept up-to-date. However the fact that many people are actively maintaining more than zero is evidence to the contrary that large, healthy open source projects can exist without a "boatload of cash" being injected into them.
I hope you're not accusing anyone here of being an "open source consumerist". I don't think it's fair to treat a simple question about whether a project is still being maintained as being some kind leeching activity. No one is asking you to do all the work, or really any of it. All we're saying is that in it's present form, this isn't working. Somebody or some people need to keep maintaining this project because a lot of folks depend on it. I have offered some help in getting started with this. I think there has been some concern raised over the ownership of the project by a company as well.
Again, no one is "enslaving" you. Just trying to find a way as a community to keep this popular library afloat. If this isn't possible maybe the community should fork. |
|
Or just use https://github.com/devote/HTML5-History-API which I ended up doing. |
|
I've started a repo for the history-acid tests that @balupton mentioned earlier https://github.com/mreinstein/history-acid I think a great first step would be to code tests that trigger all the bugs that are documented in history.js to evaluate any polyfill's effectiveness. |
|
I'm new to History.js and feel concerned by this thread. I need to use this library in production, and look forward seeing some pull requests merged. Should I find an alternative ? or will these PR be merged one day?
I have to admit this sounds interesting. |
|
@rbelouin the project is dead. given http://beta.caniuse.com/#search=history I don't think this library is that important if you're able to target reasonably modern browsers. |
|
@mreinstein ok, thank you for the reply! |
|
See #417
They still and will always behave differently, history.js's intent isn't just compat for old browsers, but compat for new browsers: https://github.com/browserstate/history.js/wiki/The-State-of-the-HTML5-History-API |
Replacing our no-longer-maintained history polyfill with native HTML5 History pushState and popState. browserstate/history.js#390 browserstate/history.js#276
Hey @andreasbernhard are you still carrying the torch on this? Or shall we find a new maintainer?
The text was updated successfully, but these errors were encountered: