Sprinkles of JS, or full frontend frameworks? What do you use and why?
3 Likes
I use both of the approaches, but I really like Turbolinks + Stimulus.
4 Likes
Should try Unpoly. 
But yeah, I focus on the site working in full without javascript, then I sprinkle in javascript to just make it ābetterā, but never required (unpoly works really well for this progressive enhancement).
6 Likes
I mostly āhad toā use React. Used ClojureScript for most of my personal works. Since Phoenix LiveView, it is and will be, Phoenix LiveView (along with a sprinkle of vanilla JavaScript here and there). It is because I can talk in Elixir better, also, it makes sense because most projects are not SPAs, I am more comfortable with using JavaScript as a way to āenhanceā your widgets, as a drop in, isolated within that widgets make-up room. LiveView lets me do exactly that with JavaScript, without having me miss a few of SPA goodies. That being said, if I have to fallback, Iād fallback to React.
2 Likes
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.
3 Likes
How is your experience with Ember? It has a reputation of being slow.
2 Likes
I donāt work with JS but Iād surely try Svelte and BuckleScript if I had the time, energy, or actually cared. 
4 Likes
It Depends 
.
I very much think that the particular scenario dictates what approach is most well-suited. There are many web-applications that can nowadays exist without any JavaScript at all (since many transitions and effects that used to require JS can now be accomplished by solely using CSS). I tend to use tiny snippets of JavaScript, often without requiring any library at all (āvanillaā) when things like e.g. tabs or expanding/contracting elements are required.
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.
4 Likes
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.
2 Likes
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.
2 Likes
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 
)
4 Likes
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.
3 Likes
That sounds extremely substantial for a web app, like Discourse forums, which always take a second or two to load where most sites just load instantly, it makes it āfeelā slow, even if the javascript is fast it still āfeelsā slowā¦
3 Likes
LiveView and nothing else
3 Likes
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.
2 Likes
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.
3 Likes
What have you built with it so far @egze?
2 Likes
If only the HTTP5 WebComponents Spec would finally finish eh? ^.^
2 Likes
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.
7 Likes
I played with alpineJs some days ago and it felt very slow.
2 Likes