Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Meteor was supposed to revolutionize web development on node a few years back, making it easy to write compelling reactive applications. I'm not very familiar with the history of the platform, but I know that since last year most of the development effort has withdrawn and gone to work on other projects. I'm trying to decide on a framework for my next application, so I wonder if Meteor is still a viable choice for the purpose, as opposed to just using plain node+react/angular/etc. These are the pros and cons I've experienced so far:
Pros:
Easy to prototype
Javascript everywhere
Publication/Subscription model is kind of neat
Reactive
Cons:
Performance is hard to get right using pub/sub
Framework updates don't come as often as they used to
Locks you in with no escape
Less people write Meteor packages recently
Adds a lot of overhead
Your question is likely to get closed, so I'll chime in here super quickly:
I've been using Meteor for the past three years or so, and I've finally decided to stop using it in favor of the following stack:
Client-side
React
Apollo
AWS Cognito (for user auth)
Server-side
Express
GraphQL (Apollo implementation)
I'm moving for some of the reasons you list, mostly overhead and adding too much weight to apps that could be a lot more lightweight and simple. I'm even thinking of going serverless and just having my GraphQL endpoint powered by Lambda.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm gonna develop an e-commerce website, and also I need to develop a mobile app for the same. Which language is preferable for both the front end and back end for this development. Initially, I planned to develop using react.js, node.js and MongoDB for the web app, and react native for mobile app. But I did some research, I got confused. FYI I have good knowledge in html, css, JS and dot net.
I agree with #FelDev. Your question is basically begging for opinionated (and possibly biased) answers.
To avoid an opinionated answer, what I would do in your situation is to think farther ahead.
I would ask myself questions like... if this store ends up being popular, will so and so features offered by this framework/language be good when it comes to performance? how about scalability? also maintenance?
For a more opinionated answer, I think I would agree with you (assuming this is for a company you are working with). ReactJS is very popular on the frontend so future employees will most likely be easier to find. If not, just use whatever you like that gets the job done. If it's for educational purposes to enhance your capabilities, why not try something new by letting this be a chance to learn a new framework? etc.
I hope this helps sort of :).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have experience in games development(C/C++/C#) but recently I started writing automated test and I wanted to learn some backend stuff. I'm writin platform for automated backups, making builds from git repo and testing. I decide to write server in Node.js with PostgreSQL. I have 0 experience in web development. Never ever have I use a database or javascript. I think homemade project like that will be a good starting point. I want to ask two questions. First: Which code design patter will be the best for learning Node.js? Second - Could you please tell me if this pre-alpha database concept is currently good or should I change it?database
No one will be able to answer your questions as you asked them but I'll try to give you few hints. First of all PostgreSQL is a very good relational database so if you need a relational database then it's a good choice but there are other types of databases like graph databases, document databases, key-value stores etc. that you should also consider when designing your architecture. For anything complex it is common to use more than one database.
It's hard to recommend any code design pattern. I can only recommend starting from a good style guide like the one from Airbnb and enforcing it with a linter - see: http://airbnb.io/javascript/ - and following a style guide writing your backend in a style supported and recommended by a given framework that you're going to use. Some examples: Express, Hapi, Restify, LoopBack, Serverless, Seneca, Koa, Sails, etc. Google all of them and read examples to see which one feels best suited for your needs.
Links to more frameworks to consider:
http://nodeframework.com/
https://github.com/sindresorhus/awesome-nodejs
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I see a lot of Javascript frameworks created recently since I've been learning web development (http://www.infoq.com/research/javascript-frameworks-2015). Do you know what kind of knowledge you need to know in order to create a Javascript framework in particular or any framework in general?
Creating a JS (or any other kind of) framework isn't something done easily, but some of the steps include:
Find a niche where no framework exists yet or doesn't cover a specific use-case, and where you have good knowledge of the problem space
Design and implement an easy to use (and, if required, future-proof) API
Publish it, e.g., on GitHub and advocate for it with a website or through blog posts
Maintain it
Hence, you'll need to know how to design good APIs, reasonable JS knowledge to build them and patience.
Note: while the initial fun starts with building out something, releasing and maintaining an actual framework is far more complex and requires time and effort - especially to build a community and once these users start requesting additional features, or your initial design considerations fall short of the new use-cases imposed by real-world usage. You can always build something and publish it to NPM, but be aware that maintaining a project in the open source community involves more than "writing code", and deprecating or deleting a framework/package can yield surprising results.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
We are starting a greenfield React.js project and are overwhelmed by all the options to use to "put it all together". There is Fluxxor, Fluxible, react-router, Baobab, Delorean, Marty, Reflux, just to name a few. We want to utilize the concept of unidirectional data flow and thus are not keen on using something like ember or angular in conjunction with React.
Our data will come from a Restful API we are building using Hapi.js so this is just a client application that will pull from the API.
Here are some other criteria we are considering:
Relatively minimalistic - things are changing so fast in this area
that if there's a big shake-up with React or if Relay suddenly drops
next week we should be able to either adopt the new way of doing
things, or come up with our own solution to it.
Well documented - speaks for itself
Technically sound - not prone to race conditions, preserving uni-directional flow, no glaring errors, solid code base
Active community - frequent checkins, responses to bug issues people post in git, etc
Any thoughts would be welcome!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I recently included Handlebars.js in a rails project, and a coworker balked at the notion. What are the realistic technical considerations when including an extra javascript library into a rails project?
Does the addition of an extraneous library significantly slow down the site delivery and user experience? Is this an example of engineering drama?
Has this been measured?
Adding additional libraries slows down the site delivery by several hundred milliseconds. It also requires some client time to parse and run its onload()-type functionality. From a human standpoint, it requires a bit of time to get used to using the new library. Depending on the level of complexity, usefulness, and time-saving of the library, this may be an acceptable tradeoff.
Handlebars is a great tool for templating, but you really need everybody on your team to be on board to use it. It's not very nice to simply introduce a brand new way of doing things without really discussing things. Handlebars is a big enough change to warrant at least a discussion, if not a vote.
If you were just wanting to put it there to see if it would work in the future, or maybe just convert over a page or two, then you should do that in a separate branch and do a quick prototype and demo for the team.
Depending on whether there is a valid business case and legitimate usefulness, you and the team can decide whether to convert your application to use it.