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.
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.
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-link class for example). I’ve also bought into Tailwind UI to help me prototype faster.
Indeed you’re right for basic implementations that satisfy purely showing/hiding, but commonly I need to add/remove CSS classes when in an open or closed state and also for controlling CSS classes to trigger CSS animations.
I don’t want to derail the thread, but happy to keep discussing in another thread!
That’s detectable via a CSS selector or so though depending on implementation, you shouldn’t need any CSS classes added/removed as it’s fully detectable in pure CSS as it is?
We are building a tool for our sales folks to help them during the pitch. The app shows current metrics of the potential customer, can run queries in Google to see how the customer is ranked, and soon will be able to make an offer and the contract.