I have at pretty simple PHP site for my bar: https://taphouse.dk
I’m going to meteorize it, to get that list of beer reactive - and later make people able to order their beer from their phones.
As I already am used to working with Meteor, and already have a backend system for all the kegs in Meteor - that part is a given.
But the view layer tech is not set yet. I’m used to React, but would not mind diving in to Vue or Svelte, fx.
“First Meaningful Paint”, including a rendered beer list, is the absolute primary metric here. And I will go for whichever view layer that will get me to an acceptable FMP with the least amount of work!
“Time to Interactive” is of (almost) no concern.
For crawling reasons, SSR is wanted, and I would expect that that is also needed for a decent FMP (Svelte might surprise here?)
The road to PWA is also a consideration, but my thinking at this point is that this site should be so simple and fast that it is not a big deal… Install to home screen and done!
I’m expecting this forum to deliver a precooked starter pack, with everything ready to go. I’ll just set the background color
SSR support is probably the most mature, altough it needs some work in meteor to do it
also decide if you need routing and which router you use
also if you need some database data in your server side rendered page, you need to take extra care. It can be tricky with pub/sub, but doable
(as an alternative, you could also try nextjs, which has ssr support with routing out-of-the-box and you could use firebase, airtable, graphcms or some other headless cms to store data)
OK, so basically you’re saying React is bad on SSR but the others are worse?
I will need a router, yes. Whichever!
I do, and it is definitely the plan to stick with pub/sub and minimongo. But as it is very little data with a very simple structure, I guess it is not a big deal to go for something else. I could even do polling!
As stated, I really do not care too much which tech - I’m just looking for “the path of least resistance” to a good FMP.
Do you think React is the way?
If it’s raw SSR speed you want then probably no one will argue that the order in terms of speed are Svelte, Vue then React. SSR is possible with all three. However, I would say that there would be negligible difference between any of them from a user’s perspective - they should all be more than “acceptable” providing your db isn’t a bottleneck.
Other than that, for a single-dev project, it’s down to personal preference.
I personally prefer Vue over React. I find React has too much boilerplate (even for an empty component) particularly when you want to use 2-way binding. I also don’t like JSX and find vue’s custom tags attributes along with pug/jade give much more readable templates. SSR is just as easy as with React.
If you want fast time-to-first-byte on static landing pages then I demonstrated how to do this with Vue here, although the same caching and critcal-CSS methodology could be applied to React and Svelte. But it sounds like you want to render actual data, so caching SSR wouldn’t be useful.
React is not bad on SSR, just the meteor support for SSR is very low level, because it neither assumes a router nor a frontent library.
So if you want to use meteor, use react-router and check the SSR documentation for react-router, maybe he meteor guide has some documentation about it.
pub/sub with minimongo is possible, altough i am not sure about the state of it.
There were some issues with meteor’s fibers. If you server side render code that runs meteor-collections, they will yield (in a fiber sense) in the middle of a (sync) render. No UI-Framework is prepared for that. Altough it usually works, there is no guarantee that it works without any bugs. E.g. in react there was a really nasty bug running on meteor server where the paralell renders would mix up data (Consider user1 loads the page and sees data from user2!) This was fixed in react, but because of another reason. They statement from the react-team was clear: fibers makes meteor a non-standard runtime and support is not guaranteed. I bet many other libraries would say that on problems like this.
You could also use a prerender-service for SEO purposes and only render client-side, its probably the fastest way. “FMP” should also be ok.
These are setting up the same basic structures, on two different view platforms - Svelte or React. The React starter also used npdev:collections which not everyone will need or want.
These could be expanded with a little more interactive boilerplate to make them more useful. I’m actually building a chat app on the react starter - I’ll see about adding some of that to react starter. I also converted everything to typescript, and it might be nice to have one for typescript as well.
As far as SSR - I haven’t had any trouble with stalled renders (everything renders reliably), but I have had trouble with memory leaks which eventually crash the server. I don’t know if these issues are related.
Don’t pre-render services only work for bots/crawelers? My cached-ssr mentioned above benefits real users as well.
Yes, memory leaks with SSR are very common. You have to be very careful what variables you store globally or even local to a component’s module but not on the actual module instance.
E.g. It’s OK to store stuff on the components’s instance (this.something) because all that is de-referenced when the render is finished and can be garbage collected. But if you store anything in a var/let/const within a component’s main module (or any submodule it imports) that that will not be de-referenced, but will also not be re-used on the next SSR, so memory will leak.
I’ve reduced memory leaks by prefixing all non-instance variable storage with if (Meteor.isClient) ....
That seems to have helped prevent memory leaks, which makes be believe that the Vue internal code is written well enough to avoid memory leaks with SSR.
That’s unlikely to be the cause in my code base, because almost all my vars are assigned as const - and never reassigned, and I never assign anything to globals. Of course, there’s always a possibility of a mistake, but I’ve been over the entire code base so many times.
What I really need is a way to measure memory usage and capture a snapshot right before it crashes. Then I don’t have to guess any more.
ah yes, sorry, i wanted to write more there. prerenders only work for bots/crawler. I meant that FMP can be ok even without SSR if your bundle size is not too big
Hi Jan - I work with react daily and I have a couple of old blaze sites.
I still love the feeling of high productivity that blaze offers and the only reason I am working with react is that I want the ability to pull in external developers - and they are hard to find with blaze experience.
So in (not so short): consider blaze for the front-end.
Me too. While I’m not going to rewrite my Blaze sites, I’m not going to use it for anything new either. Unless you can make a great case for Blaze’s FMP-speed!
I would still consider using blaze for new things if they were critical to me and if i was fairly certain that I would be the only one developing them. Again the development speed is fantastic.
Vue - even higher productivity than Blaze in my opinion and more widespread developer experience (and super simple to learn).