prepack VS next-runtime

Hello HN,

I'm considering the development of a new programming language, drawing inspiration from Rust's strengths, with a focus on compiling to JavaScript. Here what I'm considering are some key features:

Strict Type System

Algebraic Data Types

*Unsafe Mode for JS/TS Interaction*: Facilitate direct interaction with existing JavaScript and TypeScript code.

No Null Usage: Option/Result patterns to avoid null.

Trait Implementation

Backend Development Priority: Initially targeting server-side applications.

Efficient Compiler Design: Including features like dead-code elimination and partial evaluation, similar to the approach of Prepack[0] (by Facebook).

I believe this approach could bring significant benefits, especially with recent advancements like Uint8Array and worker threads.

Would this be of interest to the community? Looking forward to your insights and discussion.

[0] https://github.com/facebookarchive/prepack

You can still do optimisations based purely on Javascript semantics. This is similar to the first example you give with dead function elimination, and many minifiers do some amount of this already, but you can take it to some extremes. One example of this is the (no longer maintained) Prepack project from Facebook. The core idea is to evaluate as much Javascript as possible at compile time, with the expectation that the result will probably be smaller (albeit less human readable) than the initial code.

It's no longer maintained, but I think prepack is roughly what you're looking for.

i've had code where it intentionally relied on the wrong behavior (missing hook dependencies) and when I fixed it it caused an unintentional bug (hook fired too often or sometimes infinite rerendering). Yes it is more of a bug in the code rather than React hooks issue but it is also really hard to fix/rewrite. while i'd love to jump on the hype train projects like https://github.com/facebookarchive/prepack and how concurrent mode is still experimental after five+ years doesn't give me a lot of confidence.

Some real examples in JavaScript can be seen on Prepack[2]. Consequently it is natural to wonder whether we can AOT compile components of client side frameworks, to achieve a reduction in the final bundle size, but also to increase application execution speed.

Less or more it’s likely to happen, and could have been expected 2-3 years ago.

Especially with https://github.com/facebook/prepack. They want to eventually ship pre-compiled components rather than React.createElement() to end user

https://github.com/facebook/react/issues/7324

I also think this is why facebook had been investing in `prepack` - https://github.com/facebook/prepack

I say "when it works" because it's not necessarily supported by all hosts. For example, Vercel of course supports it, but Netlify doesn't currently appear to. As for other hosts, you'd need to verify with them, but I'd imagine it varies.

View on GitHub

Note: at the time of writing this, there is a bug in Next (13.4.7). Although Next guarantees that you can use both app router and pages router in the same project, there is a bug that causes a full page reload when you browse from an app route to a pages route or vice versa. This is unfortunate but does not influence our tests.

So adding an edge function was the only workaround I found. Apparently it's an issue they're working on and I think it should be set as high priority since trailing slashes matter for SEO.

Here are a great guide on what to use when: https://github.com/netlify/netlify-plugin-nextjs/blob/main/docs/redirects-rewrites.md

It also seems like an unconscious acknowledgement that their add-on services (form handling, post-processing, identity, analytics, auth, etc.) are woefully inadequate in some cases and uncompetitive in others. $20/mo for form handling beyond 100 submissions? Okay, maybe. But the feature set is so bare it's laughable. There's minimal to no customization for notification emails, no confirmation emails, and their post-processing for form detection will bring the speed of your build pipeline to its knees on any serious site. On one site turning off post-processing yielded a build time reduction of more than double the actual build time of the site.

Not to mention the fact that by foregoing any concept of a server and forcing everything into some flavor of lambda they've created a scenario where every framework with any such functionality requires open source shepherding to function on their platform[0]. At best they've diluted their initial mission and at worst they've created an unmanageable mess. They can't even make Next.js work on their platform without causing what should issue 404s to return 500s instead[1]. The SEO implications for that are a potential death sentence and that issue has now been open for five months.

I was very optimistic about Netlify at the outset, and it worked great and still continues to work great for our test cases where we've deployed individual LPs. Where the pain seems to start is anything above a thousand pages or more, which is also coincidentally where the stakes start to get higher. I don't know how they could expect anyone at an enterprise or growing business to seriously scrutinize this platform and view it as ideal with that in mind.

[0]: https://github.com/netlify/netlify-plugin-nextjs

I don't think Netlify supports WebP currently: https://github.com/netlify/netlify-plugin-nextjs/issues/687

I made the template here using NextJS, because Netlify has a NextJS plugin, which automates the process of using serverless functions. I inserted the call to my StepZen GraphQL endpoint in the pages/api folder to keep sensitive info off the client.