141–150 of 258 posts
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…
You're absolutely correct that most of this is, strictly speaking, unnecessary to get a basic React project off the ground. But one idea I don't think gets credit from folks not actively involved with front-end development is that medium-to-large scale front-end developers have very few choices regarding the runtime environment of their code- especially at B2C companies. Your scripts have to eventually be Javascript, and your stylesheets have to eventually be CSS. It's incredibly tedious to write reams of this stuff in a way which works across browsers. Moreover, libraries which abstract across browser differences (like jQuery) need to be transmitted to the client, and eat up runtime.
If you're looking to just hack around with this stuff, try just using one piece at a time. It's relatively easy to just `npm install --save-dev babel-cli` and use it completely independently of Webpack- just letting it happily do its transformation thing.
1. Babel "presets" are basically just individually-packaged sets of syntax transformations that Babel can uses to transpile your code into ES5-compliant Javascript. If you don't give it a preset, Babel will happily transform your code into... exactly the same code. If you give it the ES2015 preset, it will transform ES2015 syntax constructs into equivalent ES5 constructs. If you also add the JSX preset (as is common in React projects), it will convert JSX syntax into the corresponding React function calls. For instance, would be converted into React.createElement("span", { className: "hello" }). Various other presets apply other transformations, but the general idea is to allow developers to begin using language features in their codebase which don't have full support across browsers.
2. The thing with Gulp is that it's a great general-purpose Javascript build system, but its primary use case became transpiling and packaging assets for single-page applications. Integrating these build steps into a pipeline tended to be frustrating- there was a disconnect between what people wanted to do (I just want my assets transpiled, compressed, and bundled, kplzthx) and what they had to implement to do that (writing and wiring up Gulp tasks). Webpack kinda turns that on its head- it implements bundling via its various plugins.
3. Because this tutorial is using a lot of Webpack loaders, and until you kinda grok loaders, it's going to be unclear what's going on.
4. From my understanding (which is admittedly rather limited), postcss is very similar to babel: the idea is to allow you to transpile different syntaxes into "standard" CSS. The analogy goes sort of like "sass/less : postcss :: coffeescript : babel". Again, it's a power tool. Personally, I use Webpack's sass-loader, because I already know SCSS pretty well and I haven't had the time to really look into postcss.
5. How much CSS wrangling have you done in your career? Lemme tell you, CSS can be a massive pain to deal with once your app reaches a certain size, and that can't always be managed fully by methodologies like SMACSS. These are power tools which (are intended to) allow front-end developers to establish some amount of control over a language that's interpreted dozens of different ways, depending on the browser it runs on.
6. That bit did seem slightly extraneous- although I do appreciate that part of the tutorial is going into detail about how I might finagle Webpack to do exactly what I need it to do.
7. Because the output of these tools needs to be different for development vs. production. A comparison in systems languages might be building a C program at low optimization levels and with debugging symbols during a development build, and then a highly-optimized version during a production build.
8. Yes, so many libraries. Other languages (for better or for worse) have extensive testing frameworks, but fully testing web applications also requires means to simulate a browser so you have a good testing environment in the first place. Remember, this is a tutorial for a large-scale web application- automation and consistent testing is crucial unless you actually like paying tons of money for a bunch of QA engineers.
9. All this does is transform pure JSON files into Javascript modules. Literally, this all it does: "https://github.com/webpack/json-loader/blob/master/index.js". Any time you see a loader, what you're getting is a transformation from a source format into a Javascript module (which webpack then compiles into its Javascript bundle).
10. See 8.
I'm no Javascript Boilerplate Fatigue apologist, but there are many comments in here that are treating this as a "Learn how to use React" tutorial. This is not what is advertised nor the stated reason this article was written. From the first sentence: "we get a lot of questions about how to build large applications with React and how to integrate external APIs" Large application strucutre, external integrations...not…
Sorry, but even the “Getting Started” guide on React's website requires that you have a "CommonJS module system" installed which, if you don't, means you have to make an intelligent choice between Browserify and webpack, which means you have to do some minimal research into what those are (and probably research "babel-js", while you're at it), install one of them using npm, which may require that you install or upgra…
People assume that writing an APPLICATION for a browser is easy, which is why people get stuck maintaining monstrosities that are disorganized, not composed and tens of thousands of lines of spaghetti. Writing an application in the browser deserves just as much respect as one would give towards setting up the database & schema or creating a service layer.
That lack of respect for front end code is a big reason as to why front end projects have crappy code. React is a real break from this on so many levels... Yes, you'll need (webpack|jspm|browserify) with (babel|typescript), and likely (postcss|less|scss) in place closer to the start than the end. Much like if you're writing code for a desktop application you'll likely need at least an IDE installed, and potentially several libraries close to the start.
My current tooling of choice is webpack + babel, depending on the project I may bring in scss or less, and react tooling as needed. Using CSJ or ES6 style module syntax means cleaner code that's easier to restructure. Using webpack means being able to bundle resources in a logical flow. Working on a project without webpack + babel is just painful by comparison... I'm working on an ng1 app at work that's less than 6 months old, and feels like it was written in 2011... having to add .js files to some common point, and not being able to easily refactor services/controllers/directives/components into discrete modules is pretty painful in general.
What does it take to get a Java application going? Maven, some build system, some other tooling, and understanding the component/class hierarchies? It's not any easier than working with any new tooling.
Is there some churn, yes... is it that bad, not really... going to browserify mainly means that you can have references from a starting point into your application's code... each piece requires in its' dependencies. From there going to webpack adds in other dependencies and custom loaders. Babel is a translation layer... these tools generally build on or are supersets of the tools that came before.
Earlier quoted context omitted.
> 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…
Definitely true in general, but I think it's more noticeable in the JS world. Look at Java + Spring, C# + ASP.NET, Python + Django, Ruby + Rails: these are all examples of popular frameworks that have been around for much longer than any single JS library (except jQuery), and are all still in high demand.
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…
What are you doing with python and go that "just works"? Writing scripts? It takes a lot more work to build a yelp clone with python than it does with react.
Anything you want. Dependency management is taken care of by a simple `pip install flask`, or a requirements.txt. The rest depends on the packages you are using.
> It takes a lot more work to build a yelp clone with python than it does with react.
And why do you think that? I could build a simple and performant Yelp clone with full authentication, admin access, and persistence using only a handful of Python packages:
* Flask: web app microframework
* Jinja2: view templating language
* SQLAlchemy: database ORM
* Psycopg: Postgres database driver
* Flask-SQLAlchemy: Flask plugin for SQLAlchemy
* Flask-Login: authentication, accounts
* Flask-Admin: administration
Of course, just like in the case of React, you'd need HTML + CSS for styling, and JS in case you'd like interactive elements. And finally, to run the app in production, I'd use Nginx + uWSGI.
Earlier quoted context omitted.
>I'm not blaming react, everything else in the javascript space is just as bad right now. There's at least 4 different ways of loading modules (UMD, AMD, commonJS, es (babel) modules), 2 of which (require(), import .. from) are used within this example. Personally, I got so frustrated with ever-increasing complexity of tools and growing networks of dependencies that whenever I can I try to package my JS code in self-…
Sounds very anti-DRY, though I get where you are coming from.
Earlier quoted context omitted.
I've shared your frustration. The Hello World experience is a huge spectrum ranging from the 30 screens of setup you describe to the one-click Visual Studio installer. The other thing to consider is what you assume from a reader in a tutorial. If you assume they have a full environment setup (or will be following another tutorial), you can put together a much more concise article. Imagine the now-classic Rails Blog i…
I really feel like this isn't a general problem, but rather a problem with a subset of development environments. Node (backend) definitely doesn't have a similar problem. Want an express app? Install node -> npm i express --save -> node app.js. Go doesn't have it either, whether you're using the base tool or GVM. Python requires a minuscule setup in virtualenv, but beyond that its straightforward. Elixir and Rust are…
Front end applications of any kind of complexity are NOT simple... treating them as toys, and expecting them to grow in complexity doesn't work.
Seriously, how can people be blasting older technology like Flash and Flex (which was GREAT), out of the water for not using web standards and then this Frankenstein of a "stack" is going so mainstream.
Sure, there is the VM problem, but the language was good and so was the framework. This looks horrendous and scary. Imagine maintaining this for the next 10 years when "the standards" will have moved on to you "next gen" javascript "framework".
My only way to write web apps has been using micro frameworks, jquery, and small libs that do one thing and one thing only. I can handle serving pages with Go thanks, and I don't need a routing system that looks like a vintage joke. Sorry if I sound jaded, I've been doing this for 15 years.
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…
$ npm install --save react react-dom
$ npm install --save-dev webpack webpack-dev-server babel-core babel-preset-es2015 babel-preset-react react-addons-test-utils
module.exports = {
entry: 'src/index.js',
output: 'dist/bundle.js',
module: {
loaders: [{
test: /\.jsx?$/,
exclude: /node_modules/,
loader: 'babel',
query: {
presets: ['es2015', 'react']
}
}]
}
}
import React from 'react';
import ReactDOM from 'react-dom';
const MyRootComponent = (props) => {
return Hello World
};
ReactDOM.render(MyRootComponent, document.getElementById('react-app'));
...
...
$ webpack-dev-server --content-base static/
To me this epitomizes what I feel as I'm trying to explore options for different front-end frameworks. In this article I'm 30 screens down (literally 30 page down presses) and it's not even finished setting up the environment and dependencies. Sure, this is something that you only do once, so if it then leads to much better development workflow it makes sense to have a solid investment upfront, but it makes it very h…
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…
The reason there's so much to do, is there are so many options... core parts of the tooling for modern js are fairly consistent... node is pretty much required, which brings npm.. understanding CJS and ES6 module syntax also required... a translator (babel|typescript|traceur) are pretty much required, as is a bundler (webpack|jspm+system|browserify). That'ss 1 x 3 x 3 potential configuration vectors without starting the application. Each has advantages and disadvantages... I'm webpack + babel myself.
From there you have React, you need an orchestration layer, which has started to settle on Redux for all but the most complex applications. If you need async workflows, you're probably going to need redux-thunk and a communication library (fetch or axios). Beyond that, it depends on your needs specific to the application. If you need more than one route, then react-router and binding to redux.
Everything beyond that depends on the specifics of your app and needs. There isn't a one size fits all.