Entrepreneurs? Why not more interest

community
5

Simple answer - many companies decide for techs by given requirements. If the requirements demand certain features that a certain technology solves best it is used. Okay the actual process is more complicated but I think you will understand the essence.

Now what if these requirements are not present and teams are free to choose the tech? Mostly they will decide for what is backed by the team’s skillset.

If this is not even present, because there is no team or the team is not skillful enough, the decision will mostly target the most popular tech on the market because it has the highest chance to find developers or companies to deal with that tech. These devs are also usually cheaper and this explains to me why people still use php (OMG).

This can lead to wrong decisions where the tech may not be the right solution for the problem and this is mostly caused by missing incomplete requirement analysis, missing or incomplete specs or insufficient time that has taken into analysing the project goals (sometimes called quick and dirty or milestone driven development).

5 Likes
6

My context is similar to this: I come from a business background and am starting a new company. There are basically 3 alternatives:

  • Hiring a freelancer to develop and then eventually hiring devs to manage
  • Inviting a dev to become your co-founder/CTO
  • Learning to code yourself

Option 1 is cheap, but the result is often not satisfying and in the end, starting a digital business with no coding experience is like opening a restaurant without knowing how to cook: It is possible, but far from ideal.

Option 2 sounds easy but is actually very, very hard. It goes way beyond just the technical skills of the person.

So I opted for #3 and started to learn how to code. After months wasting my energy on the common JS path (React/Redux + Express), I discovered Meteor and finally stopped hating and started loving code. But many friends who are professional developers tried to talk me out of using Meteor because it is “too opinionated” and “inadequate for anything ambitious”. Bullshit. Meteor gets things done quickly, easily and with clean, manageable, easy-to-update code - which is what most startups really need.

12 Likes
7

I think the answer is in your premise. Entrepreneurs usually don’t have technical skills so they delegate to developers to just build what they want. They don’t care about technology unless it is inherent part of their business.
If entrepreneurs have technical skills then their selection of tech is like @jkuester and @patrickcneuhaus explained, Meteor nowadays is sadly a bit obscure so there is a good chance that they haven’t heard about it or the outdated BS from other developers and online articles. Only a few whose needs are satisfied by Meteor and can resist the BS will actually make it to Meteor.

1 Like
8

maybe if main meteor websites give more visibility to resources like https://www.youtube.com/playlist?list=PLLnpHn493BHFYZUSK62aVycgcAouqBt7V the learning curve will seem more affordable for people who come from php and are afraid of the javascript jungle

3 Likes
9

We need to get passed that “Meteor was still a thing” attitude that I often hear :stuck_out_tongue: anyone interested in making fresh tutorial sites and youtube posts?

2 Likes
10

Actually the issue here seems deeper then Meteor given the latest NodeJS surveys. Somehow the majority of the NodeJS ecosystem believe that it’s better to have many small packages than any opinionated framework. Also NodeJS ecosystem got dominated by front-end libraries and large cooperation stack.

I’m not really pleased by that mindset, given that node allows you to write both the client and the server in theory it should be the ideal ecosystem for the web startups and entrepreneurs, but practically it’s not, somehow developers believed that stack that worked at Facebook such as React, GraphQL, Redux and webpack are also the go-to tech for a new startup and medium size business. Both Ruby on Rails and PHP has a great framework for entrepreneurs, NodeJS has Meteor, the difference is that with RoR and PHP, the developers and the entrepreneurs wholeheartedly supported those frameworks because they know they don’t have the budget of large cooperation like facebook so they support those tools for themselves and their fellow entrepreneurs, they’re all on the same boat, yet somehow in the NodeJS developers are convinced that the facebook stack is the starting point when it’s obviously 3x the cost/time of doing it even in PHP. But Facebook is the king of the hype and the herds. I think any entrepreneur with business sense should rally behind a framework like Meteor/Vue because they simplify the process and reduce the number of decisions needed to generate value to customers.

8 Likes
11

Thanks everyone for the comments. I got from a different area IT and pre-made solutions are always preferred when faced with a business problem. I get it learning the new shiny toy gets you a cool job at a tech company, but I’m more interested in generating revenue than learning the next new tech stack. I know a few laravel developers who do very well for themselvs and can launch new products that can make up 5-10K a month in sales if its the right project. If it fails they shut it down and move to the next idea. All the built in tooling and deployment options make rapid development so much eaiser. I’m just not sure why in the javascript world this hasn’t caught on. Are more people interested in the tech vs the value you create?

1 Like
12

Then I think you’re in the right place :slight_smile:

1 Like
13

Im’ also saying this as someone who got a lot of Cisco certifications and got to the high bill rate, and one day I realized if I put that much effort into learning asterisk, php, and other open source I could have made way more $$$$ and way higher customer satisfaction with less of my time being devoted to dollars for hours and more value for the customer. This is my take away after being in tech almost 15 years.

6 Likes
14

I can think of few. The thing is, you approach it from a business point of view. Most developers don’t. Business means getting profit and reducing TTM (Time To Market). Software development is essentially the same, because business software is of course being built for… business right? So what is the problem? The below picture illustrates it pretty well. It originates from Martin Fowler’s book Refactoring:

As you can see it traditionally takes time for a good software system to become productive. It takes planning, hard thinking, talking, learning, discussing, and a lot of refactoring. Meteor in that sense feels counter intuitive, because a lot of that stuff has been done. Now suddenly the developer has to focus on the actual problem domain. A MVP can be profitable within just a few days with Meteor without having to boilerplate, glue, build API’s, decide on JSON structures, caching and clientside storage + reactivity. Especially when you use existing design systems like Bootstrap, Material-UI or Vuetify. I’ve built systems with Meteor that became valuable after just a few minutes of programming.

Business people love it, but developers get scared. Its simply too good to be true!

Reason 2: Meteor in context
Meteor on its own provides a huge business value. It also makes a lot of developers very happy. Development in Meteor is lovely - that is - for as long as you follow the Meteor approach to handling data, transpilation, API requests, the database and hosting it. Going against the opinionated flow of Meteor might get you in trouble - especially if you don’t have a lot of experience. Funny thing is though that Meteor simply follows some pretty good standards so there should be no reason to go against it.

In real life, software systems are part of a bigger ecosystem of tools. The simple scenario is where Meteor would work as a SAAS Dashboard where customers log in. This is where Meteor shines, but almost always there would be a need to build a simple static website that acts as the landing for prospects. I’ve worked at companies that had dozens of landing pages and just one platform. Today its less of an issue, but Meteor was not always good at static site building and things like SEO, multi-site support and had quite a bundle size (for example Minimongo is still part of the bundle).

Another example is the API. In reality, many bigger organisations have API’s all over the place. To leverage Meteor’s pub/sub system you will need a way to make requests on these API’s, bundle it and publish it in your publication. That’s why MDG came up with Apollo.

Reason 3: Meteor had its issues
What is still a big strength, but becomes less of a thing since (MDG tries to move away from it) is Atmosphere and its smart packages. While its a very powerfull way of adding isomorphic packages without having to configure anything, it is not what the javascript community wanted. NPM became defacto and therefore Meteor had to open up to NPM packages aswell. NPM support was not that pretty just a couple of years ago.

The build tool is powerful, but ‘was’ slow and had some issues. Many potential Meteor developers that tried Meteor stopped using it, because they got stuck on the build process (also in dev mode). “There is something broken, but I have no idea what”. Most of the Meteor magic happens in Meteor’s core. Good luck figuring out what went wrong if you wernt the one building or maintaining Meteor. What most people don’t get though is that the opposite is also true: “Good luck building your own flawless zero config platform using webpack”. Developers unfortunatly take a “Do it yourself” stance, since that’s how most developers became developer in the first place…

Not only that. There is the Dunning Kruger Effect - A coginitive bias that makes unexperienced developers think that building their own system would be possible within short notice and with just their own knowledge. They forget that MDG is a team of bright people, each with their own strengths and knowledge that work full-time on this platform. Good luck…

Reason 4: Blaze was the only choice for the clientside
Blaze is a very powerful view layer. Besides Vue I personally find it the best rendering framework of these days. Even better then React, simply because it works so well and intuitive. Not everyone is fan of Blaze though. To give an example: When React came in the picture, people wanted React, but couldn’t, because it wasn’t supported. Luckily it didn’t take long for MDG to realize that going against the greater JS community is not a battle they could win so they decided to make React the first class citizen of Meteor, causing a small uproar in Meteor’s community, because what about Blaze?

MDG did well here. They’ve made the right prediction and I did some very successful projects with React. I’m also very happy to see that Meteor now also supports Vue.

Reason 5: Marketing and communication
While the technical side of Meteor is briliant, there is almost no communication to the outside world on social media. The javascript community did not hear about Meteor’s adoptability that kept it bleeding edge even though there was a revolution going on in the Javascript landscape. For me as Meteor power user the transition from ES5 to ES7+ and the adoption of new concepts like reactivity HMR was flawless!

The community did not hear about Meteor’s legacy builds and Meteor’s zero config React integration, its flawless integration with Apollo and capabilities to build a simple Rest API using Webapp.

There is many more to mention, but I don’t think the platform Meteor is the issue here. Most issues are solved and its now a very stable platform. Its the Javascript community and how developers look at developing software. That’s why we need to step in. Promote Meteor, share your love, your success stories, share how Meteor helped you and don’t listen to people that laugh Meteor away simply because they didn’t try it.

23 Likes
15

Thank you for the thought full reply. I think you hit the nail on the head with it just being too easy and devs are left to actually think about the business.

16

We’ve been using Meteor to build an enterprise data platform, and we’ve raised over a mil to do it in the last year. We’ve been using Meteor almost exclusively for the last 3 years. But Meteor fits perfectly in our case. We developed a real-time database platform that’s easy enough for employees to use, they don’t need an IT team to run SQL queries or make custom interfaces for finding relevant business information. We also are using GraphQL and Apollo to connect to different database systems. I don’t personally get the anti-Meteor sentiment. There’s nothing wrong with it. It cuts down development time and costs substantially. I’m the CTO and have been developing products for 13 years. I used to work with MySQL and PHP back in the day. I could maybe understand if you don’t need real-time, or the bulk of your app needs to work with a different database other than Mongo, or if you aren’t making web apps but instead websites that need fast startup time. In those cases, Meteor isn’t great. But in my opinion, most reasons poeple give for not using it are because they want to find a reason not to use it. Want to control every aspect of your stack? Sure, use webpack, node, some weird pub/sub thing you find, express, and whatever other concoction you want to throw together yourself if you absolutely need total control over every aspect of your stack, because sure you might be as big as Facebook some day. But really? Ask yourself.

It’s a short sighted way of thinking. The cost savings alone and speed to market will more than make up for any insufficiencies in the tech (not that there are many). And you can use that money to deal with any scalability issues when they happen. But you’ll never get there if you bog yourself down in the details.

20 Likes
17

Agreed @michaelcbrook and congrats on your success!

Just one comment regarding the startup time, I think by leveraging SSR/Dynamic Imports you can get an initial render below 1.5 seconds, we’ve relatively large apps that loads with the data in less than 1.2 seconds, without SSR/Dynamic Imports it used to be 4 to 5s.

Also, I think the value of of a framework like Meteor extends beyond real-time. The whole philosophy behind Meteor is convention over configuration which borrows from Ruby on Rails, traditionally in every programming language and ecosystem there was a dominant framework because frameworks abstract common patterns, reduce the cost and time to market, so unless someone has a large budget, surplus of time or want to do something radically different then there is really no justification for re-inventing the wheel, it’s not just re-implementing those patterns that is costly but also maintaining them. That’s why NPM is full of abandoned open source packages, because maintaining any code beyond the hype and the fun require long-term commitment and discipline which is why I’ve tones of respect to Benjamin!

That’s why I also stated that, to me at least, it seems that the NodeJS is still not a mature ecosystem and many developers are just experimenting. All the large players (Uber, Wallmart, Netflix, Facebook etc.) created their own tech and stack. But when more entrepreneurs/SMB get into Node, this kind of churn and re-inventing of the tech will make much less business sense and will be reduced, I hope!

@michaelcbrook I’m curious what front-end library are using for your stack?

4 Likes
18

We’re still using Blaze to be honest. It works well. It’s easy to use. It’s still, in opinion, the easiest frontend framework to use when building in Meteor. And I’ve done my homework. React, in my opinion, is still very complicated and is difficult to maintain, especially when you have a company with multiple developers and another developer needs to work on something made by someone else. I’ve looked into Vue with a lot more interest. What I like most about Vue is it doesn’t require a build system. So this is not really a big benefit when working with Meteor, but I like the idea that I can cross pollinate code between a Meteor app and perhaps a more basic frontend website that could benefit from having reactivity, but has an unsophisticated backend and doesn’t need all that Meteor offers. But we haven’t gotten to the point of actually adopting it yet in our company. For the foreseeable future, we’re still sticking with Blaze for our core apps.

But this supports this theory I’ve had that maybe we’re seeing a lot more packages go unmaintained nowadays mostly because of the age of software. I can think of many packages on NPM and various software that is no longer maintained (kind of like Blaze) because it’s simply “done.” It doesn’t require many more improvements. There’s a growth curve to everything in life and it moves not exponentially but in the form of a sigmoid. You find this in business but also in nature. Biologically, as humans, we grow rapidly in the first dozen or so years of life, but then our growth slows. It would be unreasonable to expect technology to grow counter to the laws of nature. The way growth can continue, however, is with major innovation. We would see a “step up” in the sigmoid curve in this case. I liken this to Apple’s release of the iPhone. But every NPM package and every piece of software will not hit a major technological breakthrough, nor should they always. It’s more the exception than the rule, and it’s often the combination of apparently separate pieces of technology that induce a technological breakthrough. And that’s what our jobs, as programmers, are. I get frustrated sometimes too when a package is incomplete or not maintained, but 9 times out of 10, someone else has already forked it and made it better or made another package that fits my needs. If no one has, well then that’s my opportunity to make one and share my creation. This brings us all closer to being able to combine technologies to come up with those massive innovations. But this is largely dependent on your unique perspective of the problem and the solution maybe only you can offer. I can’t expect the computer chip manufacturer to be an expert in making phones. And there’s something to be said for specialization, which projects tend to lose sight of when they try to artificially “innovate” just to inch the curve up. There’s also the economics of it - many developers are not getting paid for their open source work. But this improves with the sharing economy. The burden of work is “distributed”, lowering the opportunity cost of each contributor. But this is why it’s important we don’t solely rely on others to do the work for us. The machine moves forward only when people contribute.

Like a lot of things in life, the progress of an ecosystem, of a technology, of a society, of a species largely depends on your answers to two questions: What am I looking to get out of this? And what am I willing to give?

12 Likes
19

I’ve built a few client projects with Meteor before and I’ve always loved the direction where it’s going.

With that said, the stack I’m using for my startup is Vue + Express (serverless) + Airtable. While airtable is slow and not so much a replacement for mongo, it allows everyone else to quickly enter in stuff in the DB (create lots of new content) right out of the box, and the site can pull it right in.

When we add auth, might consider using meteor again. Firebase seems unmanageable in the long run. Meteor still feels like a black box to me, even after having built several sites on it. I didn’t like how the front and backend were so tightly coupled.

With that said, I’m exploring Prisma + GraphQL at the moment. Will see how that goes!

20

Serverless is no-go for us since we need to have control over our backend to serve enterprises.

Airable doesn’t sound to be useful for anything serious and frankly I dread spreadsheets, there is reason why excel hell is a thing, the last thing I want to have my databases as as spreadsheet, in fact spreadsheets used to be the storage mechanism before databases got invented.

Firebase/Prisma are both backend as a service and again it’s a no-go for us due to complete lack of control over the backend, but I think those are good if you want to get get a mobile app to the market quickly, so you need to pick the right tools for the job.

That’s an architectural choice, you can just use Meteor as a backend with GraphQL or RPC end-point and build the front-end with something else.

Also I’m not sure how you’re managing so much churn of different tech stacks while serving clients!

2 Likes
21

For sure, there are so many variations / stacks / services it mostly comes down to personal preference.

The stack running costs $0/mo for me, and allows other people to collaborate with me (I’m the only dev on the team, everyone else is a journalist or biologist). We’re running a small project, not Airbnb. But I’m about scale it up, which is why I’m moving some aspects away from Airtable (they’ll still use it, more or less as a CMS). Btw do you know of any Airtable-esque interfaces for Mongo? There’s a reason Airtable just got a huge funding round. They make stuff fast, easy, and reliable.

For Firebase/Prisma, totally agree — what I give up in control I gain back in speed and cost (and frustration, since I’m the designer/dev on the team, and we run on a $0 budget).

Interesting using Meteor as backend. Do you run a Node server with Meteor? And Meteor does the mongodb wrangling for you? Does Meteor act like an Apollo backend (since it’s the same team) and you can just run GraphQL queries? I’m gonna look into that. There are way too many tech options out there lol. I just want something low cost, cheap, fast, for a chat-like app. It’s Firebase vs. Meteor vs. Prisma right now.

Churn of tech stacks — basically I was doing Meteor/React for a while, but that was slow to dev (ugh React) and costed money to deploy Meteor server. For my latest project I’ve moved onto a completely free low-tech stack (Vue/airtable/serverless). Basically airtable so I didn’t have to build any backend interfaces lol.

1 Like
22

Ah, now it makes more sense given the background and constraints you’re faced with.

Yes exactly, at least in that case you’ve control over a backend that you can build on, perhaps you can ask your biologist colleague a 1$ each to afford a 5$ droplet on digital ocean :sweat_smile: but yeah they won’t be able to just modify the data like a spreadsheet also if this something short-term or a POC maybe serverless make sense.

23

Ok so I’ve had trouble figuring out the difference between Apollo and Meteor. If I just run Meteor as purely a backend, isn’t it more or less like Apollo?

I remember super frustrated back in the day when Meteor would change/break a lot, which is what led me to look at other stacks. My relatively-simple Meteor apps would also be absolutely massive for some reason.

(As for cost, if I used Prisma, I’d have to deploy it on DO or Heroku anyway, so oh well)

24

Well I don’y really run Meteor that way, I’m using DDP/RPC. But one of the directions (although it’s not there yet) is to make Meteor an entry point to GraphQL using Apollo, so yeah you’ll be just using Meteor as a build tool and a server and Apollo to serve the GraphQL requests.

I’m not sure when did you use Meteor it but I think over the last 3 years it’s been stable with new features added in backward compatible way. With regards to being massive, for me it’s mostly the client code, specially with React there is a lot of code to write and libraries are changing very quickly. I’ve not changed any backend code since I start using Meteor due to an update, but with React, every few months there is a breaking change.

1 Like