• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Web Design and Development |OT| Pixel perfect is dead, long live responsive design

Hey guys, need your input. So I'm applying for web developer jobs at a couple of companies, but they're either asking for "contributions to the open source community" or github profile. What are they looking for? How can I give them what they want?
They want proof you know what you're doing. Build a couple of websites, host them somehow, and leave the code on GitHub. A portfolio of projects is better than open source contribution but if you have any of that then add that too. They want to see that your code is decent. They also want to see that you know how to document, use git with decent commit messages, have error handling, etc. The stuff a degree doesn't teach you.
 
Hey guys, need your input. So I'm applying for web developer jobs at a couple of companies, but they're either asking for "contributions to the open source community" or github profile. What are they looking for? How can I give them what they want?

Like Spoiled Milk said they want to see something you have done.

That said, contributing to open source projects is a GREAT way to learn new stuff that benefits others too and contributions can be in all shapes and sizes from new features to tiny fixes in documentation and THEY ALL MATTER! Check out https://opensource.guide/ for instructions how to get started?

Already handle Git and such? One of my NeoGAF related projects has couple of issues that are good for beginners https://github.com/petetnt/neogaf-monkeybot/issues
 

sturmdogg

Member
They want proof you know what you're doing. Build a couple of websites, host them somehow, and leave the code on GitHub. A portfolio of projects is better than open source contribution but if you have any of that then add that too. They want to see that your code is decent. They also want to see that you know how to document, use git with decent commit messages, have error handling, etc. The stuff a degree doesn't teach you.

Ok so I upload the site files to github? Do I upload all the files or just the ones with PHP/MySQL? Not sure how this is supposed to work so bear with me.
 
Ok so I upload the site files to github? Do I upload all the files or just the ones with PHP/MySQL? Not sure how this is supposed to work so bear with me.
All the files a stranger would need to have your site running. Meaning I can clone your repo and run the server with that directory as the root and it just works.
 
All the files a stranger would need to have your site running. Meaning I can clone your repo and run the server with that directory as the root and it just works.

Explaining to someone new to Git this way can be a little misleading. For instance, if you cloned my react app into a folder on a fresh computer, it wouldn't just work, you'd have a lot system configuration and need to know how to install those app dependencies, and even then, there are typically assets or configuration that you keep out of source control. For a project like WordPress (or any other typical WAMP/MAMP/LAMP stack project), you wouldn't have the LAMP executable, database, PHP configuration, etc., in your repository.

--

sturmdogg, the idea of source control is, at it's simplest, to track changes to your code in a project. It's really nothing more than that at it's simplest. Distributed source control using something like Git or using a hosted platform like Github (the most common these days) adds a lot more features and enables you to collaborate on projects a lot more easily, but at base, source control is just tracking changes to code over time. You can add anything you want to source control, but usually source control systems like Git, SVN, Perforce, and others, generally focus on tracking only code changes. Code is something that can be tracked very quickly and efficiently by a source control system, where as binary files like images, audio clips, word documents, PDFs, and other media-rich file formats really aren't tracked efficiently by source control. Usually those file formats have their own ideal change management systems, like for instance a Digital Asset Manager might be used for images or design files, or Adobe and Microsoft have their own internal systems for tracking changes to a Word file or PDF, etc. But systems like git are made for tracking code changes.

Along with binary files, most people usually do not track their database in source control. There's a long list of reasons why but usually it comes down to how efficient source control could track a large database, which is simply not very efficient. What you really want to track, in that case, is how another developer would connect to your database or be able to copy the schema of your database (the structure of it) so that they could create their own. In the first case, the "How another developer would connect to your database," this is usually as simple as committing a configuration file, and for the second case, most applications define their database schema somewhere in the app.

For your job application, it's unlikely that you've contributed much code to community/open source repositories at this point, but you can add your source code for specific projects as individual git repositories to something like Github or Bitbucket. Remember that these are usually *public* repositories, so you do have to be careful to not add files to the repo that have sensitive data in them (for instance, if it's a WordPress site, you wouldn't want your wp-config.php to be in the repo because then your database password would be public...).

Depending on the project, someone has probably written a "Best way to add *blah* to Git," for instance, "Best practices using Git and WordPress" or something. I work on a lot of WordPress projects for freelance and my rule of thumb is that I really only commit the specific parts of the project that I'm working on. So, this is usually just my custom theme that I develop and then any custom plugins. If I've added a plugin from the WP plugin repository, I don't add that to the git repository. You could but it's kind of a waste IMO because WordPress stores plugin activations in the database, so restoring the plugins for a WP site is usually more effective using the built in tools and plugin repository. I also don't store any media files, plugin dependencies (like say a backup file, etc) to the source control repository because source control isn't great at tracking changes to binary files and it's more or less a waste of storage or could be done better using something else.
 
Open source contribution is so intimidating, I read the beginners guide previously and I have no idea where to start.

My feelings on that currently:

b7e.jpg
 
Open source contribution is so intimidating, I read the beginners guide previously and I have no idea where to start.

My feelings on that currently:

b7e.jpg

First of all, pick a project that seems interesting to you. Check for the issues for starter bugs and volunteer to work on them; disclose that you are a beginner because if the issue is labeled as starter bug, it usually means that the maintainers are usually very friendly towards newcomers (if they aren't, well screw them and move along). Do your initial implementation and ask questions if you get completely stuck. Show your progress and usually someone will point you the right direction.

Remember that contributing can be much else than just code: issue triaging, pull request reviewing, documentation updates (! even from small typos), art... for example I started contributing to open source by triaging issues on Adobe's Brackets project and I am now one of the core contributors on that project and contribute to other open source projects almost daily.
 
Why is statelessness so important to React? I read their tutorial and some explanations but it reads like the cargo cult fp nonsense from Haskell and Clojure a decade ago finally found its way into Facebook culture.
 

ferr

Member
Regarding getting your toes wet in contributing to OSS, start very simple. I started by just looking for a typo in a popular repo, and made a pull request to correct the typo, just so I could get a feel for their contribution process.

First of all, pick a project that seems interesting to you. Check for the issues for starter bugs and volunteer to work on them; disclose that you are a beginner because if the issue is labeled as starter bug, it usually means that the maintainers are usually very friendly towards newcomers (if they aren't, well screw them and move along). Do your initial implementation and ask questions if you get completely stuck. Show your progress and usually someone will point you the right direction.

Remember that contributing can be much else than just code: issue triaging, pull request reviewing, documentation updates (! even from small typos), art... for example I started contributing to open source by triaging issues on Adobe's Brackets project and I am now one of the core contributors on that project and contribute to other open source projects almost daily.

Know of any books or articles that go over best practices for handling branching? Like for example, having a branch for each dev or each feature, having a "live" branch, etc.. and how that all fits into CI/CD and automated build/tests.

I feel like if you asked 10 shops how they do it, you'll get 10 answers, but there's probably a high level concept that they're all aligning with.
 

Lister

Banned
Why is statelessness so important to React? I read their tutorial and some explanations but it reads like the cargo cult fp nonsense from Haskell and Clojure a decade ago finally found its way into Facebook culture.

I know very little about React, so I could be way off base, but as I understand it it's all about doing more funcitonal programming.

It's about the power of composition. Breaking up your dumb components into reusable, generic functions that you can string together to create more complex UI compoenents. Makes testing super easy and the atomic approach to development probably means keeping things very decoupled, which si also good.

It's also about keeping the store as THE place where state is held. Not strewn all over your components.
 

Copons

Member
Why is statelessness so important to React? I read their tutorial and some explanations but it reads like the cargo cult fp nonsense from Haskell and Clojure a decade ago finally found its way into Facebook culture.

I'm a React developer barely using any FP, we try to use stateless components wherever possible mostly for leaner code and the possibility that eventually in the future maybe FB will optimize them over stateful components.

At the same time though, if we need an internal state (say, `this.state.isExpanded` to toggle a dropdown), we just go stateful and call it a day.
No reason to manage components from outside or even from Redux making it hard to track down stuff, when you can just add a state property and a method.
 

D4Danger

Unconfirmed Member
I think I'll do localization / translation as my OSS contribution for now. Seems like the easiest way to get my feet wet. Thanks!

I'll just say from experience if you can provide localization/documentation/corrections for OSS that is a really big help. I had an extension that had a few translated strings from English and they were terrible. People would occasionally just ping me corrections that made more sense for native speakers which were super helpful.
 

sturmdogg

Member
Crap. Looks like I'll have to learn JS as well as do OSS contributions. Since when is JS required to create websites?

Anyway, should I start with vanilla JS or should I go straight to frameworks like React / Angular?
 
Crap. Looks like I'll have to learn JS as well as do OSS contributions. Since when is JS required to create websites?
It's required for any website anyone would pay for :p
Anyway, should I start with vanilla JS or should I go straight to frameworks like React / Angular?
You need to know JavaScript as a programming language to use a framework at all, since a framework is just a library that helps you build applications. As for manipulating the DOM and basic web stuff, it's not that complicated. A client side web app sends web requests and changes the changes elements in a web page, that's it.
 
Know of any books or articles that go over best practices for handling branching? Like for example, having a branch for each dev or each feature, having a "live" branch, etc.. and how that all fits into CI/CD and automated build/tests.

I feel like if you asked 10 shops how they do it, you'll get 10 answers, but there's probably a high level concept that they're all aligning with.

Like you said there's tons of ways to do it (successfully), so the rule of thumb is to do whatever the others are doing. If you are in charge of creating a rulesheet of some kind of best practices, follow the path of least resistance. There's things like GitFlow that are rather strict and really robust, and there's just making stuff up as you go and something in between like GitHub Flow. Mostly they are just semantics and many things that work on any smaller projects don't work on massive ones (say your own teams project vs. NodeJS that's maintained by hundreds of contributors).

Some common things that I enjoy across our own projects and other OSS projects are:

- Master should always reflect the current state of the codebase; I often see things like development branches being used, but that's just confusing to me. Develop features on their own branches, merge to master and cut releases from the master. If you need to totally revamp the structure, then using something like a @next branch is feasible though
- Branches should be short lived, and the occasional long lived branches should be periodically updated against the latest master
- Naming schemes don't really matter, but the branch names should reflect what's in them. If you want to prefix them as bugs/branch-name or features/branch-name, that's okay but not mandatory.
- All the commits should be reviewed by someone else than you, or if you are the sole contributors it's still useful to drive your commits through the common chain (for example with projects on GitHub/Lab: new branch, push commits, open a PR early, run the commits through CI tools, address commits, merge to master and delete the branch).

Why is statelessness so important to React? I read their tutorial and some explanations but it reads like the cargo cult fp nonsense from Haskell and Clojure a decade ago finally found its way into Facebook culture.

Managing local state for tons of components make larger applications rather unpredictable and passing down state breaks encapsulation. Many times when you think you need state, you most likely would be better off passing just plain props. That said, if just managing state locally works for you, you should definitely go for it. I absolutely love Redux and know people that can vouch for MobX, but unless you know your way around React, its props and state, going all in on state containers can be really confusing.
 

GHG

Member
What's the slickest way to integrate a Twitter feed into a website these days?

My client wants there to be the presence of a Twitter feed on their homepage but wants it to look slick. So I'm thinking a small 3/4 line slider that displays the 5 most recent tweets once at a time with a transparent background.

Is there a simple way to integrate something like this? I don't want a Wordpress plug in by the way.
 

ferr

Member
- Master should always reflect the current state of the codebase; I often see things like development branches being used, but that's just confusing to me. Develop features on their own branches, merge to master and cut releases from the master. If you need to totally revamp the structure, then using something like a @next branch is feasible though
- Branches should be short lived, and the occasional long lived branches should be periodically updated against the latest master
- Naming schemes don't really matter, but the branch names should reflect what's in them. If you want to prefix them as bugs/branch-name or features/branch-name, that's okay but not mandatory.
- All the commits should be reviewed by someone else than you, or if you are the sole contributors it's still useful to drive your commits through the common chain (for example with projects on GitHub/Lab: new branch, push commits, open a PR early, run the commits through CI tools, address commits, merge to master and delete the branch).

Awesome, thanks! Thanks for the Gitflow link, I forgot about that and should try re-absorbing its process..

I was on a hackathon where we were expected to push out 20+ user stories within 4 hours, with a 10 person team (6 of which are actual devs). The main hiccup that seemed odd to me was the testing process and how to handle it within the CI workflow. Basically, if 6 devs (even paired down to 3 teams), are actively pushing features.. how do you handle a constant backlog of tests? We ended up just coming up with our own policy:

(note that we were pushing maybe once every 10 minutes something that was "build/test" ready, between our team, so lots of pushes, and honestly we needed to be pushing faster)

1) Every merge is its own branch with an incremented number (i.e. branch-build-009)
2) Every new branch kicks off its own CI workflow
3) The build/test server has a folder that corresponds to the build number, which a tester can run a script to spin up that version
4) Approved builds published to prod

We had issues,
- The tester had to have hawkeye vision to map the build to the specific feature(s) they were testing. The slack notification with the commit message and build ID was the simplest mapping for them. This made things difficult when they had a constant stream of builds.
- When a bug was found, the dev team was notified. Awkwardly, all builds currently in the test queue had to be ignored until the bug was fixed and merged into the CI. This caused additional issues of, "ok, we fixed that bug, but skipped testing 5 builds, now i need to test the features that were in those 5 builds.. hope i remember to do that!"

Feel free to say "NO!! THAT'S ABSOLUTELY WRONG!"...
 

Tathanen

Get Inside Her!
What's the slickest way to integrate a Twitter feed into a website these days?

My client wants there to be the presence of a Twitter feed on their homepage but wants it to look slick. So I'm thinking a small 3/4 line slider that displays the 5 most recent tweets once at a time with a transparent background.

Is there a simple way to integrate something like this? I don't want a Wordpress plug in by the way.

You could just... make it? Hit the Twitter API on some kind of interval, add the tweets to your DOM, animate with CSS.
 

GHG

Member
You could just... make it? Hit the Twitter API on some kind of interval, add the tweets to your DOM, animate with CSS.

Ok cool, it's the first time I'm dealing with integrating tweets to a website so wasn't really sure where to start but I've been looking into the API and it seems like it's something I'll have to custom build since the defaults look terrible.
 
Awesome, thanks! Thanks for the Gitflow link, I forgot about that and should try re-absorbing its process..

I was on a hackathon where we were expected to push out 20+ user stories within 4 hours, with a 10 person team (6 of which are actual devs). The main hiccup that seemed odd to me was the testing process and how to handle it within the CI workflow. Basically, if 6 devs (even paired down to 3 teams), are actively pushing features.. how do you handle a constant backlog of tests? We ended up just coming up with our own policy:

(note that we were pushing maybe once every 10 minutes something that was "build/test" ready, between our team, so lots of pushes, and honestly we needed to be pushing faster)

1) Every merge is its own branch with an incremented number (i.e. branch-build-009)
2) Every new branch kicks off its own CI workflow
3) The build/test server has a folder that corresponds to the build number, which a tester can run a script to spin up that version
4) Approved builds published to prod

We had issues,
- The tester had to have hawkeye vision to map the build to the specific feature(s) they were testing. The slack notification with the commit message and build ID was the simplest mapping for them. This made things difficult when they had a constant stream of builds.
- When a bug was found, the dev team was notified. Awkwardly, all builds currently in the test queue had to be ignored until the bug was fixed and merged into the CI. This caused additional issues of, "ok, we fixed that bug, but skipped testing 5 builds, now i need to test the features that were in those 5 builds.. hope i remember to do that!"

Feel free to say "NO!! THAT'S ABSOLUTELY WRONG!"...

Sounds like you are on the right track, but you are having some slight issues with both the continuous and the integration part.

Some of the following depend a bit on how long your CI pipeline takes to run and which tools you are using, but most points stand. Big things to note here is that you shouldn't be afraid to move fast and break things, one would be automating what you can and the last one would be focusing on the tooling a bit if they get on your way.

First of all, having a staging area that represents the current state of the application is incredibly useful. Usually testing each individual branch by hand is not needed; before a branch gets merged to master the branch should be verifiable locally and bugs should be caught in the review process. CI builds / tests should be ran against the branch itself and against master, this way you will immediately notice if either the build just fails or the tests fail. Most CI tools should do this by default default. Only test against the latest master and latest commit; there's no need finish building every commit if you already pushed changes in. Always rebase against master before merging and run the tests again if there's any new changes. Don't be afraid if the staging area breaks for a while. That's why you have the production version that is cut from a working release.

Make sure that you have enough tests to catch most basic errors. At minimum have a test to see that the app launches. Automate what you can. Focus on static analysis and create as many code tests (unit or otherwise) and you can catch 99% errors before pushing anything in. Integration / end-to-end tests are more finicky and harder to replicate locally, so your tester should focus on those.

If you want to test _any_ build online, make sure your tooling enables that; you are pretty much 75% through there: you have a system to spin up any version by hand: if you can automate that (make the CI pipeline spin up the version for you and give you an URL for example), there's no need to remember convoluted schemes like branch-build-number things.

If you are doing incremental changes or something blocks your, focus on those first. This would prevent situations where you have builds waiting for another to finish. Try to build features and make changes that are standalone as possible; this way different people in your team can move at different phase, still making continuous progress.
 

ferr

Member
Sounds like you are on the right track, but you are having some slight issues with both the continuous and the integration part.

Some of the following depend a bit on how long your CI pipeline takes to run and which tools you are using, but most points stand. Big things to note here is that you shouldn't be afraid to move fast and break things, one would be automating what you can and the last one would be focusing on the tooling a bit if they get on your way.

First of all, having a staging area that represents the current state of the application is incredibly useful. Usually testing each individual branch by hand is not needed; before a branch gets merged to master the branch should be verifiable locally and bugs should be caught in the review process. CI builds / tests should be ran against the branch itself and against master, this way you will immediately notice if either the build just fails or the tests fail. Most CI tools should do this by default default. Only test against the latest master and latest commit; there's no need finish building every commit if you already pushed changes in. Always rebase against master before merging and run the tests again if there's any new changes. Don't be afraid if the staging area breaks for a while. That's why you have the production version that is cut from a working release.

Make sure that you have enough tests to catch most basic errors. At minimum have a test to see that the app launches. Automate what you can. Focus on static analysis and create as many code tests (unit or otherwise) and you can catch 99% errors before pushing anything in. Integration / end-to-end tests are more finicky and harder to replicate locally, so your tester should focus on those.

If you want to test _any_ build online, make sure your tooling enables that; you are pretty much 75% through there: you have a system to spin up any version by hand: if you can automate that (make the CI pipeline spin up the version for you and give you an URL for example), there's no need to remember convoluted schemes like branch-build-number things.

If you are doing incremental changes or something blocks your, focus on those first. This would prevent situations where you have builds waiting for another to finish. Try to build features and make changes that are standalone as possible; this way different people in your team can move at different phase, still making continuous progress.

I left out some important aspects that you noted,
- Before pushing new code, we had a policy where you must first pull the latest, merge (manage any conflicts), `gulp build` and `gulp test`, then upon success, push. This ensured at least locally we had a build/test automated verification. However, I think this is a policy we just made up on our own, that could be handled more smoothly with an approach like Gitflow..
- Once pushed, our CI hook would clone, build, and test automatically. Upon success, slack notifications were sent, the build numbered branch was created, and that branch was cloned to the build numbered folder on the test server (essentially a user in the loop / user acceptance testing phase).

I would say that most of what the tester did during that manual test phase was run selenium manually to verify cross-device compatibility for the new feature. It was typically things that were harder (or we just didn't have enough xp to automate) to auto test -- things like, is our new widget displaying correctly according to the spec.

One aspect of testing I'm just lost on is the non-functional side. Testing JS methods to see if they return some sort of data is easy. But how do you test something like.. `clicking preview button displays a blue modal that fits the window correctly` .. I haven't dabbled much in selenium, but I assume that would be its area.
 

Somnid

Member
One aspect of testing I'm just lost on is the non-functional side. Testing JS methods to see if they return some sort of data is easy. But how do you test something like.. `clicking preview button displays a blue modal that fits the window correctly` .. I haven't dabbled much in selenium, but I assume that would be its area.

You can use Karma for running UI tests. The hard part is efficient setup for tests, making sure the tests are all async and not super brittle but otherwise it's not a whole lot different than normal unit testing.
 

Lister

Banned
I'm just going to say, if they ask me if I know Javascript, that I know JQuery. By they I mean the people I'm applying for.

I would say something like: "yes, I know js, and I have (some | extensive| what have you) experience with jquery".

What do you guys think? Someone replying that they know jquery to the quesiton: do you know js, would come off as noobish to me ;) I'm guessing this is an entry level position though? In which case it probably doesn't matter. They probably just want to know how much they'll have to teach you to catch up with their current workflow.

But yeah js is the language (and you'd probably do well to read up on the different versions and what is currently supported in browsers vs what you can develop with and then transpile later), JQuery is a js API for interacting wiht the DOM.
 

sturmdogg

Member
I would say something like: "yes, I know js, and I have (some | extensive| what have you) experience with jquery".

What do you guys think? Someone replying that they know jquery to the quesiton: do you know js, would coeme off as noobish to me ;) I'm guessing this s an entry level position though? In which case it probably doesn't matter.

But yeah js is the language (and you'd probably do well to read up on the different versions and what is currently supported in browsers vs what you cna transpile during development ), JQuery is a js API for interacting wiht the DOM.

Actually I've been a web designer / developer for the past 19 years. So listen kids, this is what happens when you get stuck in the same company for almost a decade doing small websites and WP installs. You miss out on a lot of the new hotness. Now I have to play catch up. Weeeeee!!!!!
 

Lister

Banned
This is what happens when you get stuck in the same company for almost a decade doing small websites and WP installs. You miss out on a lot of the new hotness. Now I have to play catch up.

And the lingo, jeebus, you have to spend hour sstudying just the lingo and buzzwords around current development to seem competent in some people's eyes, which is ridiculous.
 

grmlin

Member
So go and get the basics of JS, it's not that hard :) Especially if you did some sort of web development for that long.

There are online courses or good books, it's worth your time.

If jQuery is all you did in the past, something like React, Angular or Vue will pretty much be like another language :)
 

sturmdogg

Member
So go and get the basics of JS, it's not that hard :) Especially if you did some sort of web development for that long.

There are online courses or good books, it's worth your time.

If jQuery is all you did in the past, something like React, Angular or Vue will pretty much be like another language :)

I'm already doing the JS section of freecodecamp, and going through a React and Redux course on Udemy. I guess I'm just feeling pressured to learn 4 or so new languages / technologies in the span of a couple of weeks to be able to land a new job.
 

grmlin

Member
I'm already doing the JS section of freecodecamp, and going through a React and Redux course on Udemy. I guess I'm just feeling pressured to learn 4 or so new languages / technologies in the span of a couple of weeks to be able to land a new job.

IMHO, the learning curve of React, and Redux in particular, is very steep. So good luck! In the end it needs real projects anyway to get really comfortable with it.
 

ferr

Member
I'm already doing the JS section of freecodecamp, and going through a React and Redux course on Udemy. I guess I'm just feeling pressured to learn 4 or so new languages / technologies in the span of a couple of weeks to be able to land a new job.

Angular2 is probably the most used out of those.

VueJS, for me atleast, was the easiest to pick up and learn -- really good documentation coupled with a minimalistic framework. I found React to be offputting, but I may have just not stuck with it long enough to drink the koolaid. React is popular in Android/iOS development as well thanks to react native, so that's a plus.
 

RSTEIN

Comics, serious business!
Forgive me if this is not appropriate/the right place. I have no idea how to integrate API stuff into a website. I subscribe to data feeds from a leading fintech data provider. They have a fully documented API. All I need is to get set up with an example request (e.g., latest Apple news, latest stock price) and then I can duplicate this for various other securities. Anyone have any experience with this? I have posted this on upwork but if any Gaffers are looking for freelance work please PM me.
 

GHG

Member
Forgive me if this is not appropriate/the right place. I have no idea how to integrate API stuff into a website. I subscribe to data feeds from a leading fintech data provider. They have a fully documented API. All I need is to get set up with an example request (e.g., latest Apple news, latest stock price) and then I can duplicate this for various other securities. Anyone have any experience with this? I have posted this on upwork but if any Gaffers are looking for freelance work please PM me.

Every API is different. Post the API here and what framework your website is built on and I'm sure we will help where possible. You might not need to pay anyone for it in the end.
 

RSTEIN

Comics, serious business!
Every API is different. Post the API here and what framework your website is built on and I'm sure we will help where possible. You might not need to pay anyone for it in the end.

Thanks. Someone reached out to me from here. My site is a business so I'd rather pay & help out a Gaffer than just mooch off of everyone's knowledge. If the person isn't familiar with the API then I will return :)
 

grmlin

Member
I recently looked into React Native again, and I'm pretty blown away.

I'm (among other things) a React developer and always liked the idea. But when tried it shortly after it released I quickly put it away... it was not there yet.


but now, wow. They must have put a shit ton of work into it, really works like a charm.

Anyone knows how good it works in the long term? Is it a viable solution if you don't have the time to learn native (iOS/Android) app development? I'm just playing around here, so I can't tell how it scales in bigger projects.


thanks all!
 

GHG

Member
I recently looked into React Native again, and I'm pretty blown away.

I'm (among other things) a React developer and always liked the idea. But when tried it shortly after it released I quickly put it away... it was not there yet.


but now, wow. They must have put a shit ton of work into it, really works like a charm.

Anyone knows how good it works in the long term? Is it a viable solution if you don't have the time to learn native (iOS/Android) app development? I'm just playing around here, so I can't tell how it scales in bigger projects.


thanks all!

I'm interested in knowing this as well. There's an app I intend to build (personal project) and I'm trying to decide whether I go with something like React/Meteor and whether I should make it a PWA.
 

KiKaL

Member
I recently looked into React Native again, and I'm pretty blown away.

I'm (among other things) a React developer and always liked the idea. But when tried it shortly after it released I quickly put it away... it was not there yet.


but now, wow. They must have put a shit ton of work into it, really works like a charm.

Anyone knows how good it works in the long term? Is it a viable solution if you don't have the time to learn native (iOS/Android) app development? I'm just playing around here, so I can't tell how it scales in bigger projects.


thanks all!

I have been working in React Native for close to if not more than a year now. I have built 4 different apps. I have had to do things with audio manipulation, geotracking and geofencing and an app that is a single app that is responsive to if the user is on a tablet of phone. I am a pretty big fan and have had great success with it. I will say using React Redux to handle data is a must in my opinion.
 

Somnid

Member
I'm interested in knowing this as well. There's an app I intend to build (personal project) and I'm trying to decide whether I go with something like React/Meteor and whether I should make it a PWA.

PWA all the way, nobody has to approve it and that is powerful especially as lock-in is getting more aggressive. There's just so little native offers anymore. The downside is of course Apple support since they know what a threat this is to their ecosystem and have done everything they can to delay implementing certain features.
 

ferr

Member
I have been working in React Native for close to if not more than a year now. I have built 4 different apps. I have had to do things with audio manipulation, geotracking and geofencing and an app that is a single app that is responsive to if the user is on a tablet of phone. I am a pretty big fan and have had great success with it. I will say using React Redux to handle data is a must in my opinion.

That's awesome to hear. Do you have access to react UI components in react native? I imagine it gives you a familiar react-like API to native system components (like setting up push notifications, getting GPS, interfacing with game center, etc..)
 
I've read less than good opinions about react's licence. Something about your license to it gets revoked if you are litigating with Facebook.

It's not the license, it's the patent grant, which is by far very wrongly understood. The common misconception is that the patent grant will grant Facebook the right to patent your software if you happen to use React in your product, or that Facebook has the right to terminate your license if you build a (Facebook) competing product, or that Facebook can terminate the clause if Facebook sues you for patent infringement and you counter sue (with something not related to something licensed under the Facebooks license (BSD+Patents)).

The patent grant however enables Facebook to terminate your license if you happen to sue Facebook on the basis of something that uses software under Facebooks license. For the vast majority of us, that will never be the case. And if indeed Facebook steals your software (idea?) and you happen to sue, you of course the opportunity of doing a rewrite of the same technology with differently licensed software, as the copyright will stand.

That's awesome to hear. Do you have access to react UI components in react native? I imagine it gives you a familiar react-like API to native system components (like setting up push notifications, getting GPS, interfacing with game center, etc..)

Answer is yes, but you can also build native modules if the components that React Native offers you is not enough.
 

ferr

Member
Looks like Alibaba (apparently now maintained by Apache??) has been working on Weex, which is basically VueJS Native. If this works well, it would be my choice of native.

https://weex.apache.org/

samples on their github- https://github.com/apache/incubator-weex/tree/master/examples

I get the feeling there would be some fragmentation in the framework implementation, but hopefully it's VueJS enough to be usable. Definitely a big difference in github stars with react native at 48k and weex at 3k -- fewer stars = fewer contributors = less support = lesser product.
 

RSTEIN

Comics, serious business!
Hello. Unfortunately the person I connected with here on GAF isn't familiar with this particular API.

You can check out the API here: http://docs.intrinio.com/#introduction

Basically I have no idea what I'm doing (REST API with JASON request). I just want simple requests (e.g., Apple stock price, latest Apple news) to show on my site. If anyone here can set me up with an example I can go nuts changing symbols for other securities.

I will gladly pay hourly whatever you think is appropriate.
 
Top Bottom