GHCJS patches. #128
GHCJS patches. #128
Conversation
|
I've got a few concerns with this patch.
All of this is aside from the broader question of whether it's really appropriate to be including GHCJS-specific code in a core library like |
|
I understand that these patches are a bit rough. They should probably be fixed.
I haven't looked into how process should be tested, but a Dockerfile like ghcjs/ghcjs#652 (comment) builds a full ghcjs compiler from scratch in order to run simple test. So that's the heavy-weight way of doing it. As you see in that Dockerfile, the first part creates a ghcjs.tar.gz distribution that could possibly be used over multiple tests. I don't know - should this be tested with the latest ghcjs or is it enough to test if using a fixed ghcjs distribution? Personally I think the full docker build from scratch is the least effort approach, although it takes maybe 30-60 minutes to pass. If stack supported binary ghcjs distributions then maybe this could be sped up further - I don't know if that's reasonable or not.
Makes sense.
I've proposed similar changes to the other core libraries. All of the patches are a bit rough, so probably need some adjustment, but I'm looking to see if there are any issues with getting them included. IMO GHCJS has been the most important project in the Haskell-ecosystem for the last 5 years, in the sense that it makes it possible to do more business using Haskell, so it not being integrated fully (the lacking 5% is hurting adoption) is a shame. Let me go into a bit of detail on this as we're using it commercially: Without a JS solution, I think Haskell is not a real contender for user-facing products - which make up a fairly large portion of the set of fundable projects - i.e. the industry. We're using GHCJS for Android, iOS and web development as there really isn't any other reliable option. There simply is no other option for keeping a unified code-base. In our startup, in 2016 when we started, the ARM port of GHC was "done", but it's likely to be this year or next year and before using that port for iOS and Android development is simple and straight forward. The ARM port has a long way to go to get all of their patches upstream. There is great momentum behind the ARM port / mobile haskell, but compared to the momentum in the JS space, it's still not enough to be cost efficient. The cost (and stability and security) advantage of being able to use JS libraries on the UI side is simply too big. We're using react native which is an eco-system with 100k's of commits focused on UI only. So even if the ARM port is stellar, it might not "solve" the UI problem, not even the mobile platforms development problem. Then we have the WebAssembly effort. If the WebAssembly effort follows a similar trajectory to the ARM effort, even if it's "done" this year, I'm not sure it will be usable for mobile/web development until 2020. The other question I have regarding WebAssembly is if it makes any difference. Is the WebAssembly's speed/memory tradeoff sufficiently good for typicaly UI-work? It seems like it does not directly fit the virtual DOM used in many UI frameworks these days. WebAssembly requires marshalling of data in and out of the GHC heap, which is at odds with the observer pattern used to optimize vdom implementations (such as (the obsolete) GHCJS creates somewhat bloated runtime representations, but if 70% of the work is done in traditional JS frameworks, and WebAssembly requires marshalling large data structures (or special-purpose workarounds) for every state update, then is it worth it? Time will tell, but to me this isn't obvious at all. All of this is not a technical argument, but an argument from a business perspective. There is a need to get GHCJS into the core libraries from a business and eco-system perspective. |
|
Author here: I haven't pushed for upstreaming or polished the patches yet for that purpose. I've mostly maintained them to provide the required functionality for building and testing GHCJS projects. Perhaps some functionality is still missing. I think that before merging this patch, the dependencies I'm working on better automated testing for GHCJS, perhaps that can generate pre-built packages to allow travis-ci builds later on. @alexanderkjeldaas do you want to help out updating/polishing some of the library forks to align them with the code/testing standards of upstream? |
|
I can possibly help with that, I just need to understand how we want to
test it. I don't think it should be too difficult.
…On Tue, 15 May 2018 at 10:07 Luite Stegeman ***@***.***> wrote:
Author here: I haven't pushed for upstreaming or polished the patches yet
for that purpose. I've mostly maintained them to provide the required
functionality for building and testing GHCJS projects. Perhaps some
functionality is still missing.
I think that before merging this patch, the dependencies filepath and
directory should be merged. Perhaps we can focus on the technical issues
first, prepare patches that are technically acceptable and make sure they
are well tested. Then we are in a better position to review the actual
impact on upstream libraries.
I'm working on better automated testing for GHCJS, perhaps that can
generate pre-built packages to allow travis-ci builds later on.
@alexanderkjeldaas <https://github.com/alexanderkjeldaas> do you want to
help out updating/polishing some of the library forks to align them with
the code/testing standards of upstream?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#128 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAUtqScJf7Bfl0Cebcr0iKIPTIuMxa5Oks5tyoxegaJpZM4T87bw>
.
|
|
Closing, there are no plans to include this for now. |
Patches from the GHCJS project.