Sprinkles of JS, or full frontend frameworks? What do you use and why?
I use both of the approaches, but I really like Turbolinks + Stimulus.
Should try Unpoly.
I’ve been using ember for years now and I don’t see myself moving away from it for another SPA framework any time soon. I haven’t tried live view yet but mostly because I have struggled with similar style frameworks as soon as the apps UX becomes more complex.
How is your experience with Ember? It has a reputation of being slow.
I don’t work with JS but I’d surely try Svelte and BuckleScript if I had the time, energy, or actually cared.
It Depends .
At the other end of the spectrum are full-blown interfaces with custom form-elements, WYSIWYG-editors or immersive single-page-applications. For those it makes sense to use a lot more scripting. In that case I recommend using one of the SPA-frameworks.
Personally I would recommend a framework that is batteries-included and has a single clear way of accomplishing things (examples are Svelte, Elm, LiveView) over something that solves only part of the problem and requires you to add other libraries to make it a full solution (e.g. React and friends):
I have worked on quite a few React-based projects and I have never seen two of these whose architectures were alike. This makes the learning curve of understanding such a project much higher, as well as having the risk of discussing a lot about which particular set of libraries is most suited for what you are currently building, rather than focusing at the problem at hand.
Don’t get me wrong; freedom is nice and one of the main drawbacks of Elm is that certain design choices it makes are (arguably overly) restrictive. However, I much prefer (in programming in general) freedom (to drop to a lower level of abstraction) be opt-in rather than the default.
Unfortunately ember hasn’t been able to shake such reputations as being slow or old. It’s very much as modern as the alternatives. In terms of rendering speed I don’t know the benchmarks but it certainly isn’t anywhere near slow, though there can be a second or two initial app boot time depending on complexity.
This very forum we’re using right now is also based on Ember.
Years ago when I started web development, I was interested in Ember, but the only thing which stopped me from learning it was web developers calling it slow.
It’s definitely worth another look if the opportunity arises. I would imagine the learning curve is probably the biggest hurdle to adoption but if one can accept the ember way it yields great benefits such as stability and easy upgrades (99% of the time anyway )
What learning resources do you recommend if I got a chance and time to learn Ember? There is a course at FrontendMasterse called Ember Octane Fundamentals by Mike North (from LinkedIn), and there is a book called Rock-and-roll with Ember.js 3. I’ve seen people saying good things about these two.
LiveView and nothing else
Yeah I agree. I think whether this is an issue or not depends on the use case.
Ember does offer a solution to this called fastboot which is a node server that renders the ember app serverside and delivers prerendered html to the browser. Then once the browser has rendered the page, ember boots up in the background and hydrates the app state.
My main issue with fastboot is it moves the scalability concerns back onto me now that I have to manage a node server. Whereas if I can accept the slower boot up time it allows me to throw the app onto netlify and never worry about how well it scales. All comes down to the age old choice of tradeoffs.
I would definitely start with the ember guides on the emberjs website. I also am a big fan of https://embermap.com. There are some great videos and podcast on there.
What have you built with it so far @egze?
If only the HTTP5 WebComponents Spec would finally finish eh? ^.^
My preferred tech stack so far:
- Elixir and Phoenix LiveView. This gets me really really far into what I need to do, both on the backend and frontend.
- AlpineJS for light user interaction like dropdowns and hiding/showing elements. The benefit here is that I can write regular EEX and LEEX the same way and AlpineJS still works, thanks to this PR.
Vue for heavy user interaction like WYSIWYG editors. When using LiveView, I have to be conscience of where mounting is occuring
- if it’s EEX then there’s nothing unusual and Vue will pick up the HTML after page-load and do it’s normal thing
- if it’s LEEX then I have to ensure that a LiveView JS hook is mounting the Vue after LiveView mounts the elements.
TailwindCSS for styling. This is incredibly declarative and puts the css closer to the HTML which I’ve enjoyed. It pairs nicely with AlpineJS which is similar in philosophy (declarative). Some might think this is pure CSS soup, but I don’t see it that way. There are plenty of moments where I extract to a CSS class to keep it more succinct (a
.nav-linkclass for example). I’ve also bought into Tailwind UI to help me prototype faster.
I played with alpineJs some days ago and it felt very slow.