And just when Symfony announced their preferred way of doing frontend work is based on Stimulus, too. Great timing.
Given how over-engineered symfony is, that's not a good thing...
symfony4+ simplifies it's architecture
Stimulus.js 2.0
121–130 of 140 posts
Re: Stimulus.js 2.0
#122Earlier quoted context omitted.
I've personally hit the point where I feel like React is my go to for anything - especially with Gatsby. * If I'm keeping it simple, it's barely different than pure HTML. * Free templating * If I need Javascript (which I likely will), it's extremely easy to add anything I need.
But you get blank page until js kicks in?
I haven't had a problem. In my experience, I can actually get content up more quickly than a traditional CMS-type system.
Gatsby does some intelligent bundling so each page is pretty much self-bundled.
* Root HTML file
* Core, common JS (cached after first load)
* Page specific JS (also cached on subsequent loads)
For me, this is 257 kB uncompressed - with most of that being the Root HTML file (I realized I don't have minification or Gzip on - which takes that down substantially). Not a tiny payload, but the content is all static so the response comes back extremely quickly.
Even at slow 3G speeds, I barely get a flash. The actual page loads just about as quickly as HN.
With modern internet, the load time is nearly instant AND is literally instant on subsequent page loads (since most of the payload is locally cached).
Re: Stimulus.js 2.0
#123Earlier quoted context omitted.
React supports server side rendering.
Sure, but where is your data and business logic going to live? If the answer is "just write it in JS" then it's no longer a question of "just use React" but "let's replace our entire stack with Javascript".
Ya it really depends. I like redis and Postgres generally speaking for data, and Ruby on Rails generally for business logic. And you can certainly do universal rendering with that easily with react_on_rails. If you do end up needing more perf, maybe go would be interesting.
Re: Stimulus.js 2.0
#124Earlier quoted context omitted.
Not if you use Gatsby or NextJS and get server side rendering out of the box
Why backend of web development is narrow down to nodejs server? How about people who use Rust/Python/Ruby/Elixir/PHP?
It's not. If you're building a backend heavy use-case, there are plenty of good options.
Gatsby is geared towards building web pages, not web applications. If you're implementing Gatsby, you're building essentially HTML pages, possibly with some JS functionality.
Re: Stimulus.js 2.0
#125Earlier quoted context omitted.
Why backend of web development is narrow down to nodejs server? How about people who use Rust/Python/Ruby/Elixir/PHP?
It's not. If you're building a backend heavy use-case, there are plenty of good options. Gatsby is geared towards building web pages , not web applications . If you're implementing Gatsby, you're building essentially HTML pages, possibly with some JS functionality.
It's interesting to me to explore this type of application that is interactive web page, but not web applications
Usually, the more interaction, the more likely it's application. The more it's just a page, the more it should be just HTML.
Re: Stimulus.js 2.0
#126Earlier quoted context omitted.
Do you think Github.com UI is complex? They are using a very similar approach to Stimulusjs: https://github.github.io/catalyst/ And it's working great?
I don't know enough about which parts of the site you're referring to to say for sure, but stimulus / stimulus-like approaches are perfectly fine for most display-only views even if they're fairly complex. There are pages in our app where stimulus works great and the UI is fairly complex from a standpoint of the number of strictly user facing behavior (click this, show X, Y, and Z). The complexity involved in handlin…
I built complex form before on financial platform where it contains complex investment details, different entities for different kind of offering .. with vanilla javascript. But that may sound grumpy old man in argument. Stimulus' weak point may be where it requires many DOM mutation per action, that's probably better use declarative way to re-render the whole thing in different way based on data.
Re: Stimulus.js 2.0
#127Earlier quoted context omitted.
React supports server side rendering.
Sure, but where is your data and business logic going to live? If the answer is "just write it in JS" then it's no longer a question of "just use React" but "let's replace our entire stack with Javascript".
Why would the entire stack be JS? Even in server side React, it can still fetch from APIs, so presumably you have a backend to fetch from, in whatever language and database you want.
Re: Stimulus.js 2.0
#128Earlier quoted context omitted.
Sure, but where is your data and business logic going to live? If the answer is "just write it in JS" then it's no longer a question of "just use React" but "let's replace our entire stack with Javascript".
Why would the entire stack be JS? Even in server side React, it can still fetch from APIs, so presumably you have a backend to fetch from, in whatever language and database you want.
So your system have two backends, the React backend and the api server? That does not sounds like a good investment.
Re: Stimulus.js 2.0
#129Earlier quoted context omitted.
Why would the entire stack be JS? Even in server side React, it can still fetch from APIs, so presumably you have a backend to fetch from, in whatever language and database you want.
So your system have two backends, the React backend and the api server? That does not sounds like a good investment.
Works fine, the NodeJS server simply builds the React page, nothing more. The API does all the heavy lifting of course.
Re: Stimulus.js 2.0
#130Earlier quoted context omitted.
Sure, but where is your data and business logic going to live? If the answer is "just write it in JS" then it's no longer a question of "just use React" but "let's replace our entire stack with Javascript".
Ya it really depends. I like redis and Postgres generally speaking for data, and Ruby on Rails generally for business logic. And you can certainly do universal rendering with that easily with react_on_rails. If you do end up needing more perf, maybe go would be interesting.
Yes but we're still going a long way from "just use React". One benefit of the "JS sprinkles" approach of Turbolinks+Stimulus is that you have a far simpler and more productive stack: Rails (or other framework) renders templates with some minimal JS on the frontend, as opposed to the inherent complexity of API + SSR + SPA. There are occasions when React is a good choice of course, but let's not underestimate the costs of the SPA architecture.