Last week, we at Special-Elektronik released a new website and retailer e-commerce called “Partnerzone” which we have been working on for about 2 years. The website uses Elm for everything thanks to Elm Pages and the e-commerce site is a “single page application” all using Elm. It’s my first real large project in Elm that reaches a production stage.
The experience of Elm as the only front end tool has been nothing short of amazing. I’m confident that these projects would not be live today without Elm.
27571 lines of Elm code (not counting third party packages)
Compiled Gzipped size: 110 KB for the largest project
Note: The compiled js includes not only business logic but also all styles (via elm-css), 46 svg icons and several svg logotypes. It blows my mind that all that fits in 110 KB.
I intend to write more about the experience and a few things I learned on the way. But I just wanted to send this out together with a big thank you to Evan and the entire elm community!
Thank you @lydell! The fix will go out with the next release.
@artjom: The categories are arranged as “rose trees”, a category can have 0 or more subcategories and the depth of the tree can, in theory, be infinite. This works very well with how I store the categories in the mysql database as a “nested set model”.
As I said earlier, speed is a core requirement, the categories rarely change and the number of products in each category is known. To make navigation between categories snappy, every category and its product count is loaded on the first page load. So when the user navigates to another category, zwilias package makes it really easy to instantly switch active category and display its children.
Richards points about raising the bar for dependencies during his Oslo Elm Day keynote really stuck in my head. But I am very grateful for the rose tree package.
I am guessing due to server-side rendering and responsiveness. elm-ui is responsive, but runs code to do it. In particular when rendering server side you do not know the dimensions of the screen being rendered to. You can guess, and fill in some default size, but when it loads on the real screen, if you got it wrong everything will jank around as it is layed out again once the elm-pages code starts running client side.
I took a look at the DOM of this site, and saw quite a few media queries. For example, I saw some to increase font size at a break width of 1024. So it is going deeper on the responsiveness than just choosing what to show/hide. I took this approach on my blog site, also made with elm-pages: blog.thesett.com.
If you are just showing/hiding stuff at certain screen widths, you can still use elm-ui and combine it with a few simple media queries for that. I think Dillon took this approach on his ‘incremental elm’ site.
I don’t know enough about elm-ui to understand whether it is possible or not, but it would be awesome if there was a version of it that only used media queries for responsiveness.
Thank you @lucamug! I do not know if you recall but I told you about this project during Oslo Elm Day 2019 when it was just an idea and an admin panel that could list categories.
The main reason why I went with Css is that I’m quite comfortable with Css, it was easier than learning Elm-UI. Also, I wanted to be able to utilize css grid and other newer css features. Much of the css is actually copy-paste from Bulma which I really like.
A suggestion though: The “Footer” flashes for a frame or two when changing to product page, (since there is no content loaded I presume). I found this distracting while browsing the page.
Looking at your description, it is very similar to what we build in one of our project at Rakuten. The main difference is elm-ui, this is why I was asking.
@rupert, yes, that is one issue using elm-ui: responsiveness together with server side rendering.
Our main app is accessible after login, so it doesn’t require SSO.
I have been doing experiment pre-rendering pages at build time with https://elm-starter.guupa.com/ and I think in one case I used some trick with elm-ui, using classes, to properly generate a layout server side.
The fact is, after using elm-ui is hard to go back to regular CSS and we are still supporting IE11, so the latest cool things of CSS are out of reach.
It seems that the next version of elm-ui may improve this aspect.
Yeah. Its actually the reason I have not learned elm-ui, since I knew I wanted to do static rendering. If I learned elm-ui first I would find it hard to motivate myself to come back to CSS afterwards.
