Deep equality comparison can generally be done faster than deep diffing (you can abort on the first difference).
1 Like
Guys & Gals,
This thread is turning into everyone’s wish list. Tiny is here for business not to make all the dreams of us (lazy) developers come true
If the platform is to become live and vibrant, a feature that is important enough will get developed by contributors (e.g. all those I want Vue or Svelte support). That’s not their job
What we should really want is:
- Tiny has to vocalize what is its business intent – How will they make this profitable. Is it via Galaxy, or support, licensing to dev teams, or Apollo-like data services or integration with existing Tiny services. This also will define who the target audience is (entrepreneurs are risky, they fail 99% of the time and want everything for free – don’t want history with MDG to repeat itself)
- This translates to improved awareness of the platform – for instance, push success-stories publicly, meetups, etc.
- Better integration into the NodeJS ecosystem (Maybe keep important packages but cleanup Atmosphere, looks shabby for any newcomer to see all those unmaintained packages)
- My opinion: React is here to stay and is by far the dominant JS view framework (holdouts seem ideological or small / single-dev teams). React HAS to be a first-class citizen to entice corporations. View-layer agnosticism would drive away interest. The React audience is HUGE and are often backed by companies. This is where interest and real money is.
My 2 cents, now back to work
8 Likes
Listening to this podcast episode about SSR in React (they mention Meteor and Apollo a few times), makes me think there still is a big opportunity for Meteor here as well.
I don’t know if it’s possible to make SSR more plug and play, but just fixing some of the gotchas should already go a long way I think. Looking at how Ben aced the dynamic imports, it should be possible to make this a better dev experience as well. You already see community efforts like this package trying to achieve the same thing.
I have the feeling the JS community is still looking for a go-to solution for this, and out of the box SSR could be a USP that makes a lot of sense for Meteor.
4 Likes
This thread is turning into everyone’s wish list.
Post Your Most-Wanted Features for Meteor seems to be asking for just that.
If the platform is to become live and vibrant, a feature that is important enough will get developed by contributors (e.g. all those I want Vue or Svelte support ). That’s not their job
Vue integration is already a feature that has been developed by contributors. It’s in the official Meteor guide.
View-layer agnosticism would drive away interest.
Why? If developers familiar or partial to a view layer come to Meteor after learning about a first class integration, that is more devs using Meteor and potentially contributing. If a company would like to adopt Meteor progressively, it would be beneficial if they could use their existing front end code base. I’m interested in using a framework where I’m not tied into a view layer or database. Ruby on Rails and Django are view layer agnostic and plenty of people use them.
React HAS to be a first-class citizen
No more than Angular or Vue does.
The React audience is HUGE and are often backed by companies.
Same can be said for Vue (Facebook, Netflix, and Adobe) and Angular (Google, Udemy, MIT).
6 Likes
Not sure what your message is as you seem to agree with me that contributors have carried the torch for Vue. My point is that it’s not up to Tiny to do all this but the community. Let’s make it short and sweet
The post title is ‘Help Tiny’, so we should focus on what is expected from the owning company by the community. First-class view layers other than React should be up to the community (maybe Angular can be up to Tiny as well, not sure)
PS: I wasn’t aware that Facebook was using Vue in any significant way
2 Likes
Core Vue contributors (especially Akryum) have worked on the integrations for Vue. I don’t know the history of how React came to be a part of Meteor and if core React members made it possible or if MDG helped out, but I imagined the community carried the torch for it as well.
First-class view layers other than React should be up to the community (maybe Angular can be up to Tiny as well, not sure)
Still don’t understand why you think they should be maintaining the React integration but leaving everything else up to the community. It’s up to Tiny whether or not they think supporting the existing integrations is important.
It’s been mentioned in here already, but the creator of Vue worked for MDG and it has been argued that it is an even better fit for Meteor than React. My point is that Meteor can be successful while not favoring one view framework over another.
1 Like
Notice the bolded part, it’s my opinion. React is by far the dominant view layer see proxy chart (Angular not far behind, but it comes with its own full toolkit). If we want Tiny to be a good shepherd, we need to help them focus on where the money is.
3 Likes
If we’re using google trends, then HTML is by far the dominant view layer!
https://trends.google.com/trends/explore?cat=31&q=Vue.js,React,Angular,html
3 Likes
Lol. I have never typed “vue.js” into Google when searching for Vue stuff.
2 Likes
A bit better: https://trends.google.com/trends/explore?cat=31&q=Vue,React,Angular
– 25 vs 100 for React
I imagine The State of Javascript and npm weekly downloads (6,117,132 for React, 1,157,084 for Vue and 465,898 for Angular) would give a better snapshot of how view layers are comparing in popularity.
2 Likes
I think the problem with SSR is that the specific tools you are using require a different set of configuration. For example, in one project, I use: React, React Router, npdev:collections, Material-UI (JSS), react-helmet-async, staringatlights:fast-render, and npdev:react-loadable. In another I use Svelte, svelte-loadable/npdev:svelt-loadable, staringatlights:fast-render, and might use Apollo (currently using straight Meteor pub/sub). These two projects will require a completely different set of tools to be configured in SSR on both the server and client.
I’ve also read that SSR memory leaks in React aren’t exclusive to Meteor, and are just generally hard to manage. In my main React project, I can’t seem to get it to stop leaking memory, though I have significantly reduced (slowed) the leak (this indicates multiple leaks). I currently suspect either Material UI, or uniforms as the culprit - neither satisfies React’s Strict mode, which means either could be creating “side effects” on mount, and causing the leak. (Or possibly some core incompatibility between hooks and/or the mongo driver and Meteor’s Fibers.) I’m not sure yet.
Opinionated Starters (like mine for react and svelte) are probably the way to make this easier.
3 Likes
I find SSR is a little over-rated, in general.
It’s a micro optimization, but gets pushed around like it’s required. You can have a wonderful non-ssr experience with a service worker.
4 Likes
Another feature I’m really interested in is a code sandbox for Meteor.
When MeteorPad went down, a lot of knowledge and examples were lost. It was frustrating to find a blog post I’d read before with the solution to my problem but not be able to access the example.
I participate in other communities (namely Vue), where it is easier to give and get answers to common problems because of the insistence on a small reproduction in Codepen or Codesandbox.io. I happily pay for Codesandbox because of the templates that are readily available, linting, and ease of isolating problems quickly. I’d be thrilled if there were template for Meteor. I’m not sure how Atmosphere packages could be required and DDP could be emulated or if it’s even possible without spinning up an instance of an application.
I’d be open to paying for one from MDG, provided I knew that they would continue support for it in the future.
7 Likes
Interesting take, thanks! Any tips for tutorials on this?
Google has the best documentation I’ve seen: https://developers.google.com/web/fundamentals/primers/service-workers
1 Like
import React from 'react';
import { render } from 'react-dom';
import Whatever from './Whatever'
render(<Whatever />, document.getElementById('whatever-target'));
This is more first-class than create-react-app, which magically sets up an html div with id="root".
2 Likes
+10 for the rational and informed business-minded perspective.
(No personal opinion on React vs. the others.)
Back-of-envelope, a full-time dev pays for him/herself if you get an incremental 50-100 well-heeled Galaxy customers. So maybe Tiny can just officially support all the major front ends.
As for strategy, isn’t Galaxy the only revenue-generating thing at the moment? A few mil/year was the guesstimate, in another thread.
+=10 for your point re shabbiness… it’s so embarrassing. Same for the official docs – For a while, the docs actually had a bug (you couldn’t reliably navigate old versions), which was kind of impressive. But even now, they are lacking. I am optimistic that we’ll see a new-management makeover.
3 Likes
Maybe Tiny is waiting for the end of these posts to take stock 
2 Likes
These posts will end when this thread is forcibly closed LOL.
Tiny - do you have enough to chew on now?
6 Likes