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.
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.
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…
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.
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.
I didn’t run a benchmark or something, but I ran some examples from the tutorial at Scrimba and they felt very slow even that the code was running on my computer not some mobile phone.
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.
One example I need some JavaScript for (and AlpineJS makes this declarative in the HTML) is mobile navigation menu drawers to open/close. I don’t want to use LiveView/server for controlling these UI elements since it’s not related to server-side data. I absolutely try to avoid using JavaScript where CSS alone works.
I don’t want to derail the thread, but happy to keep discussing in another thread!
The more I use Phoenix LiveView the less I need JS… But I still need it occasionally. When I do I use this amazing library called VanillaJS
I do try to use VanillaJS as much as possible. However, part of me just can’t let go of jQuery. It’s an old comfort blanket and so easy to use that I still find myself using it.
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?
What javascript is required for this? I’m curious as at work I have mine as just pure CSS and HTML for the same functionality. It’s a lot more battery friendly and lower network usage this way as well. ^.^
That would make for an interesting thread! How to do things without javascript that is often done with javascript. ^.^ You should start it!
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.
.
)