Gleam Has A New Web Framework

The link is not working for me. It seems to be prefixed with elixir forum

Thanks! The link should be fixed: Wisp Web Framework

Thanks for sharing @matthias_toepp ! I’m glad you’re enjoying the framework.

@lpil since you showed up in the thread I’ve got some questions for you..

1. Could you share any thoughts on the future direction/development plans of the framework?

• I’m particularly curious if there is a vision (or ideas) for some form of front/backend integration (I mean some way of offering the type of advantages offered by liveview, rpc’s etc)?

• I’m also curious about future plans for templates?

2. When should people use Gleam with Wisp vs Gleam with Elixir and Phoenix, (now and going into the future)?

Wisp will continue to gain more feature over time, though there’s no specific roadmap. Wisp was extracted from real-world Gleam web applications where solutions to real problems were iterated on over time, and the same will likely be done for future features.

There’s a number of projects doing front and back integration in Gleam in a variety of ways, such as Lustre and Sockets. You may find them interesting.

I intend to soon create a template for Wisp web apps with all the usual stuff a business web application would need to get started.

I can’t say anything about Gleam with Phoenix as I’ve never used Gleam with Phoenix, and I don’t currently have Elixir in production.

Great work Louis! I really like the Wisp website. I like how it sells the product a bit, which actually saves people some of the effort of figuring out where Wisp fits in.

It’s great to see the fast progress of the Gleam language/ecosystem!

Congratulations on surpassing F# in github stars!
As of today:

Gleam => 5.6K Github Stars

F# => 3.6K Github Stars

To be honest, I’d also love to see more BEAM programming languages getting hotter than F# on Github. Unfortunately, if we prefer to look at the stats, we should not be able to find a second one besides Elixir at this moment.

FYI:

1. https://ossinsight.io/analyze/gleam-lang/gleam?vs=dotnet%2Ffsharp
2. https://ossinsight.io/analyze/elixir-lang/elixir?vs=dotnet%252Ffsharp

Looks great! I like the context approach and how composition is done with use. Quick question: are responses immediately sent as side-effects or they require the middleware to finish?

Also, two nits if you don’t mind:

• On the benchmarks, you should link to a reproducible source. From a glance, you are comparing to languages (Go and Node.JS) and then to “full web framework” in Phoenix (which does a lot out of the box) and in none of these cases I can see what is really being compared. However, publishing the source will 100% lead to bike-shedding, so beware.

• You mention pattern matching is faster than routing in the example but that’s not necessarily the case. In Phoenix and Plug, routing literally becomes pattern matching. Someone else could also implement a binary tree (or a trie) for routes and be equally fast (or faster). You are only guaranteed to be faster than linear routing (which when I checked 8 years ago, was the case for most JS and Ruby frameworks)

Thanks for reading!

The response is sent after the handler function returns a response, similar to Raxx in Elixir.

Quite! It’s a deliberately vague statement that is intended to assure you the performance is good enough for production use. Presently I’m not interested in maintaining or discussing benchmarks as I’ve too much work to do.

Aye, I know. I’m specifically talking about Gleam there, not Elixir, which can do more thanks to macros.

If in future someone makes Gleam router that is type safe and at least as fast as pattern matching then we can revisit this and decide if it’s worth the increase in complexity. So far all attempts have failed spectacularly at both.

Gleam is looking better by the minutes. Great work, Louis!