Should I use MeteorJS for a Public Facing App? - reactjs

I have a lot of experience with the LAMP stack. I’m about to build out a new site that will be basically a directory, profiles, subscriptions, q&a etc etc. All of it needs to be indexed by Google. I’ve spent the last couple of weeks learning Meteor + React and I’m absolutely in love. It seems like I’d be able to create this new site really quickly with it.
I'm concerned about the initial load and the SEO concerns though. I see there are some workarounds with other packages to make indexing better, but will load time always be an issue?
I don't mind if there are workarounds, I would just hate to build out this large site using meteor just to find out that the initial load will always be slow. Which would wreck conversions (and SEO at the same time). Am I trying to fit a square peg in a round hole?

Related

EmberJS vs. React

Good day! I have a question. It is planned to develop a large web project, which will be scaled in the future. I would like to know what is better to choose EmberJS or React? There is experience with EmberJs, but I would like to hear the opinion of experts who have experience with both frameworks. I've heard that react is lighter, but at the same time, you need to include a lot of libraries to add functionality like ember js. Tell me, please. It would be great to see some benchmarks in various conditions. Thanks guys!
I started with React and later moved to Ember. The truth of the matter is that the core problems teams face when developing frontend / single-page-apps are about the same regardless of what tool you're using. Those problems are going to include learning the business, learning the history, struggling with how to not over-use the framework, and instead using "the platform" (using MDN more than framework docs, etc). Generally, it takes way more time to learn a business / existing product than it does to learn a framework.
For some benefits of ember's whole ecosystem, which React does not have:
Ember has a more cohesive ecosystem which makes upgrades much more straight forward.
Ember's goal in frontend is to reduce the meanial differences between apps so that you can focus on features. This includes stuff like state management, routing, etc. For comparison, there are features in Next.JS that landed in the last month or so that Ember has had since the beginning.
Ember's discord is an invaluable tool of helpful people. A bit US-work-week centric at times, but it is the go-to place to get more synchronous help outside of your own team. Link here: https://discord.gg/emberjs (which is found on the community page: https://emberjs.com/community/) -- React also has a discord, but I found it way less welcoming due to the sheer volume of people moving through there.
Conventions is key to any framework in the single-page-app approaching SDK space. Conventions are optional guidance that are happy-path defaults that, once memorized, bring productivity ahead of where it would be without the conventions
Ember is mostly "Just JS". React has this same claim, and maybe that was true back when they were using classes for things, but with everything needing hooks now, and the over-use of useEffect, Folks end up writing more React than they write JS. With Ember, you still write more JS than the framework. Ember has tried very hard to allow you to stick to MDN for for anything but reactivity and routing. State management is even allow "normal JS" (with some conventions due to limitations of JS, itself)
I've heard that react is lighter, but at the same time, you need to include a lot of libraries to add functionality like ember js.
This is true, however, It stops mattering very quickly. Ember is only 100KB (min+gzip) -- React (at a minimum, I think is ~40kb (min+gzip), with no libraries (react + react-dom)), and the size of your underlying framework begins to not matter in comparison to the rest of your app's code very quickly.
Unless you're targeting low-connectivity areas and trying to also get your site to load in < 0.1s, the framework choice w/r/t size also doesn't matter. (I'd say this of Angular, too!).
Fwiw, and maybe this is a bit of a disclaimer, I feel like React is a modern day jQuery (usage in the vernacular is nearly the same as jQuery). Nearly everyone is using it because nearly everyone knows it. It doesn't matter if the tool is good or not, it's everywhere, yet holds no opinions about anything and relies on the broader community tot learn how to use it. You can't build products out of just React.
And kind of more cynical, React is an avenue to very cheap labor for employers to hire straight out of bootcamps.
As an aside, one thing I've noticed about frameworks, is that most of the "cool stuff" (that you'd want to use day to day) isn't documented in the framework docs. It's knowledge derived from knowledge of both the framework, and what the web can do on its own.
For example:
handling form submissions without a ton of wireup: https://twitter.com/nullvoxpopuli/status/1502682732178124805
dynamic imports / await importing a component: https://twitter.com/nullvoxpopuli/status/1507715367581462531
testing with MSW:
https://twitter.com/nullvoxpopuli/status/1525509103317041152
https://twitter.com/nullvoxpopuli/status/1525508184353406978
Filtering local data: https://twitter.com/nullvoxpopuli/status/1496512125237440515
Integrating Tailwind: https://twitter.com/nullvoxpopuli/status/1481993894430658568 (the lazy way)
Thinking about template syntax: https://twitter.com/nullvoxpopuli/status/1474037335583080449

Presenting multiple/separate React web apps into one

Over the course of several years we've collected a handful of React web apps, each hosted somewhere and each having their own source code repository.
Now we are looking to sort of "consolidate" these various web apps into a single place. The effort here should be minimal (we should not spend that much time or resources on this).
So im trying to find a solution that provides a great balance in the following:
Easily maintainable
Minimum effort in terms of resources/time spent
Intuitive and very usable for our end-users
What would be a balanced solution?
I've considered solutions involving "micro-frontends", but they seem very complex and convoluted. Now i am considering a much simpler solution: Perhaps the good old fashion iframe.
Any thoughts / feedback / suggestion?

Opinion - custom build website framework vs CakePHP

I have little by little built a website over the course of the past year and am now at a stage where the whole thing can go commercial, which means that I will face some tough questions regarding security, privacy, etc.
Since this is a situation where a hobby turned into a possible professional product, I am now rethinking how far I have to take this in order to really provide a product that is considered "safe" and stable.
The website was put together based on a Bootstrap 3 theme design, runs mostly on HTML, JavaScript, jQuery, PHP with Mysqli interactions and naturally has a SSL certificate. About a dozen plugins from various websites such as datatables, PHPmailer, jQuery-bootstrap-upload, blueimp gallery, etc. do the things I need them to do and I have always paid attention to properly mysqli_real_escape input values and write error handlers for all interactions. In short, there is no real framework here, things are more thrown together.
I am now being challenged that this is not considered a safe/stable solution and instead should recreate the whole website based on the CakePHP framework, which is something I am not familiar with and will take a fair amount of time to get used to and will definitely screw up my timeline.
So in short what I am asking is this: How important is it for a small and relatively simple website (i really dont do any complex code here...) to be built on a framework such as CakePHP in order to be perceived as safe and secure?
I understand there is no real answer to this, but I was just wondering whether building on an established framework like CakePHP is considered the only way to go or if a custom made framework is acceptable.
Thanks for the advice.
I was in your situation a couple years ago. I had started a site that, in the first year had about ~50 unique visitors. The second year I had about ~1500 unique visitors. What does this mean to a developer.
Optimize the response time - caching.
You need to optimize how you fetch data. Can you cache some queries? - CakePHP comes with caching Redis, Memcached etc.
Multiple Datasources - ElasticSearch, Mysql, Redis
Now that my website is huge, visitors might start to demand more functionality from the website. How do i deal with multiple datasources? CakePHP offers ways to interact with multiple datasources like ElasticSearch, Mysql, Redis
Code maintenance - Raw code vs a Framework
Do I need to google, and stackoverflow to reinvent the wheel? CakePHP comes with the best templating system and helpers.
Cutting down on development time.
If I am coding everything myself - I will spend more time developing. Using CakePHP I spend more time improving my website's data.
Decoupling
Does my data need to be managed by Cakephp, can I use Django, REST APIs etc. In the end I decoupled my website. I use Django to manage data entry, and CakePHP to present the data to visitors using Django REST framework.
No one can tell you definitely use CakePHP. However CakePHP3 , in my professional opinion, has a short learning curve. Using namespaces you can still use your current code in CakePHP and transition slowly into using CakePHP fully. CakePHP documentation is very good. You should be able to get a basic site wrkoing within an hour.

How to understand the differences of Web Frameworks, Databases, and Libraries?

Where I stand: I am a junior in college. I have a solid background in Java and C++. I've been coding websites in JavaScript, HTML, CSS, and PHP (using MySql databases) since middle school. I have only just uncovered the magical box filled with these mysterious "frameworks."
My Predicament: After reading in my spare time wikis, blogs, and StackOverflow questions week after week for the past few months, I feel that I am no closer to understanding the items in this ominous list and how they relate to one another.
Yeoman, Grunt, Linemanjs, Bower
Nodejs, Go, PHP
Mongodb, Couchdb, MySql
Angularjs, Ember, Backbone
Terms like: boilerplate, scaffolding, frameworks, etc...
What I am asking: I understand that explaining any one of the above would be a question too big for a single Stack Overflow question, but that's not what I'm looking for. What I am looking for is a guide that explains in-depth what each of these groups are used for and if/how they can be combined (ex: using Angularjs with Nodejs). I am happy with a link if an article already exists, but I have yet to find an article that covers all of the above.
El Fin: I love learning new languages (especially for the web), but right now I feel like I'm blinded, running around in circles like a chicken with its head cut off. A shove in the right direction would be great :)
I'll put this in as an answer to help clarify why this is too broad.
I think that the GREAT BIG point you are missing is that there are specific reasons someone chooses a particular framework or server environment when they start a project.
This is all dependent of a boatload of things that like budget, knowledge, availability, expected scope of the project, etc... It also may come down to, "I'm starting this new project, what is available in this work environment for me to use?"
Then you don't really get to choose. You get what you get.
So what's the best package of technologies to use? That SO depends on what you're doing.
Example: If you are building a simple site for a local store that just needs a few pages, and you want to keep your costs low. A simple LAMP solution would work fine. But if you want to design the next Facebook, even though the core of the system could be build using all LAMP (and it in fact IS), you will need MUCH more powerful servers, and MUCH better and more efficient coding. Not to mention a boatload of server space for both the site AND the database.
In many cases, when you see people pooling together what might be considered obscure technologies, all they really break down to are collections of libraries. It's like choosing JQuery over some other JS library that essentially does the same thing. One may be better than the other. But you go with what you are comfortable with.
So, when you are asking about how, why, and in which way, do people combine technologies together, there is no way to answer that at all. Other than to say, it's specific to their needs. And that's about it.
Reading articles that compare all these different things together will only give you an idea of what they are capable of, and what their limitations are. In the end, it's always a matter of opinion what is better. Otherwise we would all be coding with the same thing.
For my part, I prefer PHP over ASP. I prefer working straight out of a text editor than using an IDE or any MVC framework. I use jQuery where it's needed, but don't over use it.
But that's just me.
And I'm sure this still didn't answer your question.

I want to build a Google-friendly web app, where should I start?

I have only very basic experience with HTML/CSS and have quite a bit of experience with testing software and web apps from a consumer perspective. I'd love to launch a web application that plays nicely with Google services, similar to some of the apps you'd find on the Google Apps Marketplace, such as ManyMoon, time to note, Socialwok, etc. I'm a huge Google fan and would like to build something that's well integrated with other Google services.
If you were a total beginner and wanted to build a complex app like one of examples above (project management, CRM, etc), where would you start?
If you worked your ass off 18 hours a day, 24/7, how fast could you do it?
I've dabbled into various languages and development frameworks, and read about which apps are using what languages but it's hard to figure out what would be most beneficial to jump into. Ruby on Rails, PHP, Google Web Toolkit, AppEngine. The list goes on and on. I want to be able to build and launch my own scalable web app.
Thanks.
One bit of advice: There is no shortcut for proper experience. It took me 4 years to come to a point where I can build enterprise level web apps - even though I had the dream of building one immediately, right from the beginning. Start small and build your way up.
Even though I did hate this advice when I was receiving it... Don't try to build the next Facebook platform right now.
Now, to answer your question:
Skills:
You must be absolutely clear about server-client interaction with respect to HTTP. You will never understand AJAX fully without understanding HTTP and behind the scenes of browsers. Note: being clear and knowing everything are two different things. Be clear about HTTP.
Learn about HTML/CSS and JavaScript standards to some extent to know that they bahave differently in different browsers. In the grand scheme of things, they are not that important if you are okay with some framework that handles these for you (I recommend JQuery and JQuery UI).
Learn a little about Linux, Apache, PHP.
How to go about it:
To develop web-apps, you could start with the LAMP stack - Linux + Apache + MySQL + PHP.
First build a small web app that does something trivial - like saving and retrieving user's stuff using AJAX and a nice UI or something. I'd recommend jQuery and jQueryUI for JavaScript and UI frameworks.
Then, build a small web app that just gets data from some Google service, given a user's credentials.. I am not Google expert but I guess Google provides APIs for some services(?).
Then build an app where two people can share their data coming from a Google's service or something to that effect.
Then add your own fancy stuff.
It goes on like that.
If you are a .Net person, you could go with.. Windows + IIS + MS SQL Server + ASP.Net3.5/VB/C#. Guess what? StackOverflow is build on that stack :)
Learning about and using an MVC framework is also a good idea - ASP.Net MVC or something similar for PHP.
Minor clarification - By Google-friendly did you mean SEO-friendly? If so, Google-friendly and web-app don't go well together.
It makes sense to build a Google-friendly website not a web-app.
I would start by
brainstorming a hands-on project
identify the skills you will need to achieve it
learn them as you work through the project
set progress goals and celebrate small victories
For most people 18 hrs/day 24/7 sounds a little overly optimistic. A reasonable goal would be to form an interesting project idea and research the needed skills the first week, work through a few tutorials and maybe apply your own functionality the second week, build something 'complete' the third week, then take a step back and take another look at your original goal.
As far as choosing a project, I find a notepad helps. I'll be somewhere and think, 'wouldn't it be nice if...' and I'll go look for a solution that provides that 'what if' and find it doesn't exist. So there you go.
I would also have a look to one of the top voted questions here on Stack Overflow:
What should a developer know before building a public web site.

Resources