91–100 of 258 posts
We (Stream) are releasing a React/Redux tutorial series - you build a photo sharing app (Instagram clone), for those you might be interested: http://blog.getstream.io/react-redux-example-app-tutorials-p...
This link has no content - looks to be like a "coming soon, give us your email for updates!" page
Earlier quoted context omitted.
I have no problem with the article or its goals, but my issue is why is so much configuration even necessary for a "large" frontend JS application? Why don't we see this kind of configuration hell in other major languages? Look at Python, or Scala, or Go, or even Rust. Do you see projects requiring 10 dependencies just to setup a testing environment? Or having to manually integrate every piece of the build process in…
> We don't even have to talk about the extremely low average lifetime of libraries in the JS world; it's like a perpetual popularity contest! This is the awful truth of programming in general today. Sadly, it's a train not many of us can jump off of because of employ-ability. If popular tool/framework/language/etc is not on your resume, you're not getting called back. If popular tool/framework/language/etc is not bei…
With Angular I feel like I have to re-learn web development and do everything the "angular way", and who knows when Angular three is coming out and the "Angular way" completely changes.
And then what are the non-javascript alternatives? It really doesn't matter much because I'll have to interface with javascript anyway if I'm a professional webdev, so why would I add even more clutter to the already cluttered web dev world?
With React, I can learn a small framework that's highly extensible and basically pure javascript. I don't feel like I have to re-learn everything I know about web-dev when using react like I do with Angular.
Earlier quoted context omitted.
This is why I'm so gung ho about Elm. To create a proper React single page app, you need React, Redux, lodash, react-router, webpack, Immutable.js, babel, npm, redux-thunk, isomorphic-fetch, webpack-hot-middleware, and ton of boilerplate and configuration (which everyone does differently). You can try to assemble this yourself, or choose one of hundreds of starter projects on Github. A comparable Elm app is a lot sim…
I've no doubt Elm is simpler (considering it's more vertically integrated), but to be fair, if webpack is a maybe in Elm, lodash, immutable, isomorphic fetch, and webpack-hot-middleware would definitely be on my maybe list for React. Maybe maybes would include redux-thunk.
Ultimately, it feels like React's best practices and associated libraries try to bludgeon JavaScript into acting like a functional, immutable language. If that's the right model, I'd rather just use a language that was intentionally designed to be functional and immutable from the start. :)
Earlier quoted context omitted.
This link has no content - looks to be like a "coming soon, give us your email for updates!" page
Fair enough - but we're releasing 4 posts next week. We have a total of ten completed and in the pipeline.
Earlier quoted context omitted.
React is simple, not complex. Simplicity is like the main benefit of using React if your intention is to build a single page app. If that's not what you need, then yeah, use Rails.
React in a vacuum might be. React in the context of building a real application is not.
Ok, granted at some point you might want to pass your build through Browserify and Babel. No worries, both of those things are one liners in bash.
On the other hand, if you spend most of your time trying to make your build process the holy grail of hot-reloading webpack ES2020 isomorphic madness then you're not going to get much real work done. No one told you to do that though, and you can't blame React either. But even that isn't complexity. It's just annoying setup stuff. Real complexity grows with the scope of your app.
Earlier quoted context omitted.
If you've already setup Ruby, which most haven't if they're going through a similar tutorial for Rails.
Well, Ruby is pre-installed on Mac OS.
Great work on the tutorial. I'm sure it took a lot of time to setup, and it seems well written. However I simply won't believe that setting up a simple React app requires so much overhead. Granted, I have no experience with React, and only marginal experience with frontend web dev. As I read the tutorial, this is the list of questions I had: 1. Why do we need so many Babel presets? What do they do? 2. Why do we need…
There are simpler ways; I don't mind webpack, I just find it hideously over complex at times; if a large % of React tutorials preface the part you want to read with long, differing, detailed explanations as to how to set Webpack up, I think there's something wrong. Brunch works well, for example this is simpler: npm i -g brunch brunch new myApp -s react cd myApp npm start // server starts on port 3333 That's just bas…
I wrote parched-tasks-webapp, heavily inspired by Brunch, but built on top of gulp and browserify. It does have hot reloading.
Say you want to build a font from .svgs:
npm install --save parched-webfont
mkdir -p app/assets/glyphs/
Here's an example app to try out: https://github.com/bravenewworlddev/parched-example-app