What's your flavour of JS on the frontend?

Frontend Developer Forum Frontend Chat/Discussions
, ,
1

Sprinkles of JS, or full frontend frameworks? What do you use and why?

3 Likes
2

I use both of the approaches, but I really like Turbolinks + Stimulus.

4 Likes
3

Should try Unpoly. :slight_smile:

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
4

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
5

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
6

How is your experience with Ember? It has a reputation of being slow.

2 Likes
7

I donā€™t work with JS but Iā€™d surely try Svelte and BuckleScript if I had the time, energy, or actually cared. :laughing:

4 Likes
8

It Depends :tm:.

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
9

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
10

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
11

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 :slight_smile:)

4 Likes
12

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
13

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
14

LiveView and nothing else :slight_smile:

3 Likes
15

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
16

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
17

What have you built with it so far @egze?

2 Likes
18

If only the HTTP5 WebComponents Spec would finally finish eh? ^.^

2 Likes
19

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-link class for example). Iā€™ve also bought into Tailwind UI to help me prototype faster.
7 Likes
20

I played with alpineJs some days ago and it felt very slow.

2 Likes