State of Javascript 2018 Results

[vikr00001]

To me the most important feedback is that Meteor is going down the drain.

Please see @jkuester 's comment above:

Meteor [has] the highest rank among devs > 20 years experience (even if the absolute value is low with 9%) and the second highest ranking for devs with experience between 10 and 20 years.

[coagmano]

It would then ask you some questions

This would be an absolute killer!
All it would take is some extra app skeletons, and a bit of CLI work

[jkuester]

Considering the direction of the thread, I want to highlight that

I just doubt the methodology of how the survey interprets the results. To me it puts the factors of adoption and experienced quality on the same level while I can’t see no correlation between these two. If the range of use cases for Meteor is limited (which is why Apollo came to the table) then adoption rate is consequently lower than for example express.

From my POV MDG can intervene here without big extra costs by a more active community engagement / envisioning the future of Meteor.

No doomsday prophecies here. The opposite: I think that the next Meteor versions will reveal even more great improvement. And since there is already Meteor-Apollo integration I also don’t see any dead end for Meteor.

P.S. Besides even a total dead end would mean that only a few people are left to maintain legacy Meteor systems for big $$$. Just read about that guy from Texas who is connecting the last few COBOL developers with banks to keep their legacy systems running.

[alawi]

think that the next Meteor versions will reveal even more great improvement. And since there is already Meteor-Apollo integration I also don’t see any dead end for Meteor.

Totally agreed, well said. However Meteor is still a child when compared to the 30+ years COBOL, but it’s only in the NodeJS ecosystem a child is proclaimed dead when it’s about to peak! If all that developers want is rock-star cultish conferences, constant refactoring or a new shinny toy on their resumes then yeah they better let go of their tech stack every few years, but I think the majority of folks here are keen on delivering real value to their customers and they know how much heavy-lifting Meteor does and appreciate it’s stability, maturity and backward-compatibility.

[eric-burel]

This is a very interesting thread. I’d like to provide some feedback based on my last 2 years experience building an development company in France.

- Express is a framework for building frameworks.

Express is relevant only if you are writing a very simple API, a very complex API, or a framework on top of it. It provides absolutely 0 feature that can be considered close to creating business value.

It’s in my opinion the worst technological choice you can make if you want to create a medium sized app. I see companies failing because they stick to Express without a framework or any kind of helper to make API creation faster. They are just too slow to create value, and the more code they write the worst it becomes.

Oh, of course, you get crazy performances with Express! Provided you get a fulltime backend architect paid 100k a year to set it up. But 99% of companies does not have enough human resources to handle such low-level technologies, and clearly don’t need it. They will never ever come close to the performance limits of any modern framework (even written in PHP).

It’s the very same as Redux. Redux is nice, but it does not scale, at all, in terms of code structure, and trust me I’ve played with it (edit: it could scale with enough qualified human resources to structure and maintain the app and does scale for many companies, as Express does, but again good devs are scarce irl). It however is a nice basis to build state management systems/frameworks, see Rematch for example.

- One trend should not kill another.

The JS ecosystem suffers from trends effects. Usually the trends are justified. GraphQL is GOOD. Next.js is BRILLIANT. React is EXCELLENT. The problem is thinking because one framework is famous the others must die.

Next.js is trendy, hourray! But Next.js is frontend framework. It is meant to write frontends. Especially with React. It can replace Meteor in some contexts, of course, but every framework fits different needs. Meteor is not dead because Next is growing.

- People reject frameworks for bad reasons

The technologies I propose to my clients are Meteor (with Vulcan.js) when I need to develop the whole app, Next.js (or CRA) when I develop only a SaaS client for an existing API, Feathers for app that requires a non-Mongo database or are suited for micro-services, Express for a very basic API. I usually propose React, but sometimes Vue is suited especially when one person in the team is transitionning from AngularJS or jQuery.

I also propose Falcon for creating Python micro-services, or even Golang.

Here’s my point: each technology has its pros, cons, and use cases. It depends on the end usage of the application you write, not on the framework specification.

Sadly, people are totally irrational with this. They have a 2k€ budget but dismiss Meteor+Cordova app because they may feels slower than React Native. I mean seriously, NOBODY will ever notice that your menu is not the iPhone menu and loads 2ms slower. Nobody will ever care before you are rich enough to go full native.

- Meteor is not dying, it’s not even born. Neither is Node.js

The truth is nobody uses Node.js, in the real world. You know what people use ? Wordpress. Symfony. Prestashop. Big companies uses Java, C#, .NET and all those old technologies that I don’t even know about.

Most companies don’t even give a damn about Node.js, because people did not yet write frameworks with enough added value to penetrate the development market. People in real life use 20+ years old software, because even if they are often fed up with them those softwares do the job. The replacement rate of applications is slower than the JS ecosystem tends to believe.

The Node.js market is not even born, we should stop killing its frameworks.

- Meteor has no equivalent in the state of the art in terms of philosophy.

Because no framework is half as focused on productivity and value creation for the end user.
This makes them uncompetitive against technologies that are objectively terrible and yet actually creates value for people.

- In 2019 I am still betting on Meteor, through Vulcan

Having a modern, opinionated stack that focus on productivity allows me to get more clients, as simple as that. Vulcan provides me everything to enjoy using Meteor Apollo and React together. It’s excellent when it comes to developing professional SaaS apps and collaborative platforms of all kind.

When working on a project, I focus on my client needs, not on the name of my REST endpoints.

It’s not my only technological choice, and I won’t push Vulcan when it is not suited. I am not a fanatic. Maybe Meteor will indeed “die” in the years to come, I don’t know.

I only care about the philosophy behind the technologies I use, I only care about creating real value for real people. I think MDG gets this right and will go a long way.

[ralanyo]

You guys are still talking about this? Lol I think it was 3 or 4 years ago I built my first meteor app. Absolutely loved the framework. I came from laravel from the beginning and would have dropped it in a heart beat for meteor. However after building that app I started reading this forum and how MDG was spending all their time on the new shiny toy graphql , eliminating blaze and pushing React. At the time after reading the forums it didn’t seem clear what MDG was doing and I felt disappointed because I thought I had just discovered something fantastic and they were changing it and making it harder for me to keep up by learning new stuff.

Long story short I ran back to php with the thought I might come back some day and this will all be hashed out. But here we are years later( I check this forum every so often to keep up ) and everyone is still talking about the same thing. MDG vision and future.

Can someone just fork this thing, call it something else and have it community ran?

I look at what Taylor Orwell has built with Laravel and it’s really amazing. Unfortunately it’s PHP which is fine but once you get a taste of using javascript on client and server along with the other nicities of meteor it’s hard to not want that all the time.

[cloudspider]

Still talking. Indeed. You know… Meteor is an awesome platform. All the stuff that MDG did and does is so powerful. Just like with all frameworks, people don’t like change, so it was logical that people started complaining on the forums.

When Meteor was still Blaze only, the platform seemed to have a goal. There were some complaints though. One being the fact that a lot of people (and among them some valuable package maintainers) started liking React - the new shiny thing - and they were not able to use it with Meteor. MDG made the platform React first, which was awesome, but also ofcourse upset the Blaze people, because Blaze was built specifically ‘for’ Meteor.

The same thing is now happening with Minimongo and DDP. The two are awesome and really make Meteor so powerfull for certain systems. People however had different backends in their companies and require a bit more pluggability to be able to use for examply mysql or an external Rest api. Then graphql came around the corner and Apollo was created.

I feel what you mean, ‘we’ (including me) are often pushing MDG to share vision. That’s different then complaining. MDG does an awesome job for Meteor and Apollo, but we have no clue about their plans. Its guess work. And like I’ve explained in the above 2 examples if MDG doesnt share vision and goals, then these technical ‘switches in direction’ keep on being a point of discussion and segmentation within the community.

“Most of the time the fix is not technical” © Cloudspider

[alawi]

Welcome back @ralanyo! I came 3 years after they opened up to React and sure forking is always an option when necessary.

Just to get you up to speed, in the past 3 years we had latest node support, server side rendering (SSR), faster build times, full npm support, dynamic imports and exact code splitting, redis-oplog for scaling, differential browser bundle, meteor guide and better vue support, that’s what I recall on top of my head.

The general theme of last 3 years has been aligning more with the rest of JS ecosystem while maintaining backward compatibility which is welcomed and I’m guessing going forward we’ll see more graphql support. But I hear your point however there is nothing certain in technology and JS ecosystem changed radically in 2015 and Meteor adapted to that, so the change was necessary in my opinion but you can please some people some of the time so I don’t think these conversations will stop and it’s ok, it’s good.

[arggh]

MDG does an awesome job for Meteor and Apollo, but we have no clue about their plans

There is a somewhat up-to-date Roadmap.md in the Meteor repository.

Few of the things on that roadmap:

• Out-of-the-box support for advanced React features
• Make meteor tool installable from npm
• Load performance improvements
• Full transition to npm
• …and naturally, Apollo

Also I was thinking maybe Meteor is so good, that the core team ran out of ideas how to improve

[ralanyo]

Seems there is a lot that has been done when you put it that way. I’ve been out of the loop all but checking in here and there to see what’s going on. I really like the move toward VUE. I haven’t looked at the guide or docs in a while for meteor. I do remember them being not so good back in the day. Maybe that is the reason it’s not that popular in the survey. I’m not complaining, I think it’s a great framework.

[ralanyo]

I hear yah. The is landscape is changing so rapidly it’s hard to keep up as a developer. Graphql, serverless, new frameworks, etc…
It’s hard to sift through it all.

Sometimes I catch myself going down a rabbit hole for hours or days only to pop up and continue doing things the exact way I’ve always done them.

[cloudspider]

I really like the move toward VUE

Dunno if this is lives in MDG aswell. I’m simply trying to push this stuff, writing the guide etc. I fell in love with Vue the same way as I did with Meteor. Please let me know if and what you are missing. Hopefully I’m able to improve that area of the integration. If that’s not the case we might be able to have @akryum lending us a hand

[captainn]

I don’t get the suspicion thrown at MDG - they’ve been very open to accepting PRs (I’ve submitted a few - have you?), and there are plenty of commits all the time. It’s weird to be suspicious of a company that is literally doing all the right things. They are walking the talk, so kudos to them!

Anyway, I prefer to talk about the tech. Here’s that roadmap:

• Out-of-the-box support for advanced React features (especially SSR - I have this working exceedingly well already, but there may be some support tools that can make it even easier - any in the community can do this work - I may try to release something myself, if I can find the time) I also have a better React-Loadable implementation I have to finish up - again, not something MDG has to do. The community should be able to achieve that (and I may, if I can find the time)
• Make meteor tool installable from npm (maybe this will help on Windows - Chocolately is unreliable in my limited experience, not just for Meteor…)
• Load performance improvements - what we need here is more transparency into the bundle. The current bundle visualizer is great, but we can do better. Extant SSR techniques already help tremendously here.
• Full transition to npm - Sure, but I still want the benefits of the modern bundle, and separate entry points for server and client. Other nice atmosphere features are eager loading for certain types of things, automatic build tool additions, and the inclusion of additional asset types, like CSS, etc. These things can’t be achieved with npm right now (afaik).
• Apollo - it’s way easier to get up and running with Mongo/Mini-mongo - I’d love to see Apollo at least as easy to get started with.

Here’s what else I’d put on the list:

• Fix Windows - I’d describe Windows support as broken ATM. It’s entirely too slow to be of any real use. I’ve had to resort to using a VM to get any kind of sane development progress out of is, and I don’t see similar problems with other node.js/npm based platforms, such as WebPack. This is a serious bar for adoption and for general mindshare/branding on Windows. This should be prioritized, IMHO.
• Add a CLI dashboard with increased visibility into what the build system and server are doing (like is it still building the legacy bundle on a separate thread? What files is the server currently serving? etc.) Some like this one
• Add more transparency to dynamic-modules. I’m often not sure if my code splitting efforts are paying off, and the bundle visualizer is only of modest help. I’d love to have some kind of log mode, where it simply prints to my console (on the serer or client - or both) which modules have been requested/served.

There’s a lot of love about Meteor as it is now, technically speaking - zero-config, modern bundles, etc. (more than that, I’ve just gotten spoiled am forgetting a lot of the great stuff - accounts system is in there, etc.). Most of what I’d say Meteor needs now is simply greater transparency into what the build server and dynamic imports system is doing.

[arggh]

I’ve just gotten spoiled am forgetting a lot of the great stuff

+1 … I regularly dip my toes in other frameworks and build tools, only to discover over and over again how great Meteor is. It’s easy to forget though, if you’re only working with Meteor!

[wildhart]

• Add more transparency to dynamic-modules. I’m often not sure if my code splitting efforts are paying off, and the bundle visualizer is only of modest help. I’d love to have some kind of log mode, where it simply prints to my console (on the serer or client - or both) which modules have been requested/served.

@captainn, I get quite a clear idea of code-splitting efficacy by watching the Network tab in Chrome dev tools and filtering the list by ‘fetch’. Then the Preview tab of each request lists all the imported modules (example). In Production you might have to use a fresh Incognito window because somehow even with ‘Disable cache’ selected, previously fetched bundles are not shown.

[qnipp]

One of these days I’ll write up my method for Mongo over methods with offline first storage on the client side (it’s partly described in another thread on these forums) - all with SSR/fast-rendre.

Quite interesting. @captainn Could you please provide me the link to this thread? I’d like to see this feature in Meteor and could help in implementing it. Just contact me.

[captainn]

I’m going to write something in the next few weeks and post a draft on these forums