General advice in use cases?
Hi! Newcomer here, both to web development itself, and even more to the Haskell / IHP community (loving it so far, BTW). And I've been wondering wether IHP will be enough for the projects to come. Let's say I need to build an Instagram or Facebook-like application, or an e-commerce. Is server site rendering a good idea, or should I stick to a RESTful API and some JavaScript framework for a SPA? I'm mostly concerned about user experience, especially in the parts of the world where connection speeds and latency are not good. How does it compare, an IHP website vs a react / express app, performance-wise? Thanks in advance for your insights!
Gonzalo Muñoz Thank you for your detailed answer!
Yes, I can clearly feel this site's almost instant response, way better than any other page I visited (I'm assuming IHP's website is made, of course, using IHP).
What worried me a little was the absence of a virtual DOM and its virtues. But now that I read about Turbolinks I see that maybe it's even better. And images and other stuff need to load on any page, whatever its stack.
So, in a nutshell:
- Little to no JavaScript over the wire,
- Little to no JavaScript being executed on the browser,
- Atomic updates of the html made on-the-fly using Turbolinks (not unlike an AJAX request, if you think about it).
- Also, a server using an optimized compile of a program written in a multi-threaded language.
That would explain why this site loads in a blink of an eye.
Please correct me if I'm wrong about any of these assumptions. I'm just kind of thinking out loud to make sense of this because it's all new to me.
Zac Wood BUSINESSYup that's all right! By default IHP has JavaScript for it's auto refresh feature, bootstrap, and turbolinks.
With regards to lack of a virtual DOM: if you find that your application has pages that would benefit from using a JavaScript framework with a virtual DOM, you can absolutely use IHP with one! In fact IHP has project templates that include Elm or PureScript -- you could use React as well there's just not a project generator that sets it up for you yet. That way you can use server rendering for pages that are mostly static, and then use a framework for other pages/components where its better suited. So you get the best of both worlds :)
Gonzalo Muñoz Sweet!
Glad to hear you're enjoying your time in the IHP and Haskell community so far!
IHP and server side rendering will serve you very well as you build your web applications. A default IHP project only includes a few scripts for utilities which are cached after the first visit. On navigation, instead of wasting CPU cycles parsing JSON and rendering a virtual DOM, we simply patch in the received HTML that was rendered on the server. In my experience building client projects with IHP this results in nearly instant navigation for the client. User experience with my IHP projects is far better than any other framework I've used -- Turbolinks does wonders for fast navigation.
Since IHP uses Haskell, a compiled language, server side performance should not be an issue. There's lots of performance work that can be done on the framework, but in some benchmarks I did yesterday my IHP app was easily able to handle thousands of requests per second on a dual core server with absolutely no thought put into optimization.
Overall, IHP allows you to build you app quickly with good performance by default. So instead of spending your time trying to figure out why your webpack configuration is broken, you can be building your product. Regardless of the tech used, every app will need optimization work once it reaches a certain scale. The performance potential with a language like Haskell is much higher than something like Ruby, which is used to power some of the largest sites in the world. So don't worry about IHP/Haskell holding you back for your applications! Happy hacking :)