Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Perfectly Cromulent posted:

Except that it doesn't look like JS at all and isn't supposed to.

Does to me as long as I keep my components small, which I have the times I've messed with it. I can see why it'd flip to looking more like an HTML template if you get big gobs of layout in each one, though :shrug:

# ? Jun 16, 2016 14:31

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 22:39

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Munkeymon posted:

Does to me as long as I keep my components small, which I have the times I've messed with it. I can see why it'd flip to looking more like an HTML template if you get big gobs of layout in each one, though

Are you confusing a React component with JSX?

JSX is specifically the part of a React component that looks like:

code:

<Form>
    <FormRow>
      <FormLabel />
      <FormInput />
    </FormRow>
  </Form>

...which doesn't look like javascript at all.

# ? Jun 16, 2016 19:48

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Thermopyle posted:

Are you confusing a React component with JSX?

JSX is specifically the part of a React component that looks like:
code:
<Form>
    <FormRow>
      <FormLabel />
      <FormInput />
    </FormRow>
  </Form>
...which doesn't look like javascript at all.

I guess? I mean, it's a 'JSX file' in my mind, because you're probably surrounding that with var theForm = ( ); in the same file, so I wasn't drawing any distinction and re-reading the official docs sure isn't disabusing me of the notion.

# ? Jun 16, 2016 19:56

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I don't want to argue for the sake of arguing here. Either I'm confused as to what you're saying, or you're mistaken and now maybe you won't be (rejoice!).

Munkeymon posted:

I mean, it's a 'JSX file' in my mind, because you're probably surrounding that with var theForm = ( ); in the same file

I'm a little confused about what this has to do with JSX looking like Javascript. React components are just simple Javascript...except for the JSX that is often embedded in them.

Munkeymon posted:

re-reading the official docs sure isn't disabusing me of the notion.

https://facebook.github.io/react/docs/jsx-in-depth.html

quote:

JSX is a JavaScript syntax extension that looks similar to XML

It then goes on to say

quote:

You don't have to use JSX with React. You can just use plain JS. However, we recommend using JSX because it is a concise and familiar syntax for defining tree structures with attributes.

It's more familiar for casual developers such as designers.

XML has the benefit of balanced opening and closing tags. This helps make large trees easier to read than function calls or object literals.

Later it says:

quote:

React JSX transforms from an XML-like syntax into native JavaScript. XML elements, attributes and children are transformed into arguments that are passed to React.createElement.

None of that really screams in agreement with:

Munkeymon posted:

JSX looks enough like ES6

I mean, it looks very much like HTML and nothing like Javascript so I've got to feel like you're meaning to say HTML or you're just flat wrong or I'm going crazy.

# ? Jun 16, 2016 20:33

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

I mean a file that includes JSX looks (to me!) like JS with some HTML mashed into it, but the JS is still in control/herding the HTML around (if that makes sense?), and has to be run through a JSX preprocessor to become useful/runnable and so in my mind it is a file in the JSX 'language' which is a superset of JS. It's like how adding a TypeScript annotation to a pure JS file makes it TS and you have to run the TS preprocessor on the whole thing.

And if that's not clear, just nevermind because it feels like a useless semantic argument.

# ? Jun 16, 2016 21:00

n4: Jul 26, 2001; Poor Chu-Chu : (

He's refusing to use JSX correctly / acknowledge what JSX even is I guess.

JSX looks like XML and not ES6. Stop being obtuse.

# ? Jun 16, 2016 21:04

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

A lot of this discussion gets muddied up by how Babel has ushered in a new generation of people picking and choosing next spec features for 'their' JavaScript, such that saying 'we use Javascript' does nothing to help you understand what's going on.
Whether it's JSX, ES7 or some custom transpilation they have going on, the language we know as JavaScript is changing in ways the browser runtime can't keep up with (and possibly won't).

Long live metal.

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript

# ? Jun 16, 2016 21:09

PlaneGuy: Mar 28, 2001; g e r m a n
e n g i n e e r i n g; Yam Slacker

I have always hated jsx becase it's an XML-like syntax to replace html, an XML-like syntax.

while I agree with thermopyle, if you look at "code that is inside files that end in .jsx"

code:

var Timer = React.createClass({
  getInitialState: function() {
    return {secondsElapsed: 0};
  },
  tick: function() {
    this.setState({secondsElapsed: this.state.secondsElapsed + 1});
  },
  componentDidMount: function() {
    this.interval = setInterval(this.tick, 1000);
  },
  componentWillUnmount: function() {
    clearInterval(this.interval);
  },
  render: function() {
    return (
      <div>Seconds Elapsed: {this.state.secondsElapsed}</div>
    );
  }
});

ReactDOM.render(<Timer />, mountNode);

it looks a lot like js. that doesn't mean "jsx" isn't that little "<div>Seconds Elapsed: {this.state.secondsElapsed}</div>" bit and looks relatively xml-ish on its own. just saying.

insert my usual riot plug here because react is so goddamn ugly to me

code:

<elapsed-time-ticker>
    <div>Seconds Elapsed: {secondsElapsed}</div>
    <script>
        this.secondsElapsed=0;
        let interval = setInterval(()=>{
            this.secondsElapsed++; 
            this.update();
        }, 1000);
        this.on('unmount',()=>{clearInterval(interval);});
    </script>
</elapsed-time-ticker>

# ? Jun 17, 2016 00:52

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

n4 posted:

He's refusing to use JSX correctly / acknowledge what JSX even is I guess.

JSX looks like XML and not ES6. Stop being obtuse.

I didn't say anything substantially different than what the documentation Thermopyle quoted said, though? E: I just think that by extending a language's syntax you necessarily create a new language, thus JSX is like JS because it is JS with XML-like stuff bolted on.

Munkeymon fucked around with this message at 14:41 on Jun 17, 2016

# ? Jun 17, 2016 14:34

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Munkeymon posted:

I didn't say anything substantially different than what the documentation Thermopyle quoted said, though? E: I just think that by extending a language's syntax you necessarily create a new language, thus JSX is like JS because it is JS with XML-like stuff bolted on.

Some are more breaking than others. For example, with TypeScript, it is implemented as a strict superset of JavaScript, so valid JS is valid TS, and TS goes to great lengths to not significantly change any core JS concepts. Contrast this to CoffeeScript, which is effectively a completely different language. I would consider JSX closer to the latter than the former.

# ? Jun 17, 2016 15:54

M31: Jun 12, 2012

JSX is just some syntactic sugar, and I would agree with Munkeymon that it feels relatively natural given the context of web development. Especially after ES6 happened. I will consede that JSX turns very ugly if you start putting conditionals in there.

Also, Typescript is also less of a superset than JSX, as let x = 42; x = "foo"; doesn't work in TS.

leper khan posted:

You're talking about JavaScript, so everything already went wrong.

# ? Jun 17, 2016 16:55

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

M31 posted:

JSX is just some syntactic sugar, and I would agree with Munkeymon that it feels relatively natural given the context of web development. Especially after ES6 happened. I will consede that JSX turns very ugly if you start putting conditionals in there.

Also, Typescript is also less of a superset than JSX, as let x = 42; x = "foo"; doesn't work in TS.

It is a strict superset in every sense of the word. However, as the name should imply, it's main goal is to add types to JavaScript. So it will infer that your let x = 42; means you want x to be considered a number, and then warn you that you're being an idiot and trying to assign it a string. If you do let x; x = 42; x = "foo"; or let x : any = 42; x = "foo";. It will also successfully compile your above code and it will run in the browser fine, it will just continue to throw type errors when you do compile.

# ? Jun 17, 2016 18:27

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

M31 posted:

JSX is just some syntactic sugar,

Well you could say every language is syntactic sugar for writing machine code.

M31 posted:

and I would agree with Munkeymon that it feels relatively natural given the context of web development.

Yes, this is absolutely true.

# ? Jun 17, 2016 20:27

ROFLburger: Jan 12, 2006

I'm sure you guys get dumb questions like this pretty often. I'm trying to take all of my css files from the css directory and jam them into 'dongs.css' and deliver dongs to the browser. What seems to be happening is that everything compiles just fine, but dongs.css isn't created or served. My 'bundle.js' file is being created just fine with all of my .jsx files rendering their components in the window, but I can't get the css to show up.

Are there any glaring errors in my webpack.config.js? I'm trying to learn Webpack and I know very little of what's going on here:

code:

var path = require('path');
var webpack = require('webpack');
var ExtractTextPlugin = require("extract-text-webpack-plugin");

module.exports = {
  entry: './main.js',
  output: {
    path: __dirname,
    filename: 'bundle.js'
  },
  module: {
    loaders: [
      {
        test: /.jsx?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        query: {
          presets: ['es2015', 'react']
        }
      },
      {
        test: /\.css$/,
        loader: ExtractTextPlugin.extract("style-loader", "css-loader"),
        include: [
          path.resolve(__dirname, "css"),
        ],
      }
    ]
  },
  plugins: [
        new ExtractTextPlugin("dongs.css")
    ]
}

# ? Jun 19, 2016 05:27

M31: Jun 12, 2012

Did you import the css file from a javascript file? Webpack only resolves dependencies starting from your entry file, it doesn't check all files in a directory.

# ? Jun 19, 2016 12:50

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

ROFLburger posted:

I'm sure you guys get dumb questions like this pretty often. I'm trying to take all of my css files from the css directory and jam them into 'dongs.css' and deliver dongs to the browser. What seems to be happening is that everything compiles just fine, but dongs.css isn't created or served. My 'bundle.js' file is being created just fine with all of my .jsx files rendering their components in the window, but I can't get the css to show up.

Are there any glaring errors in my webpack.config.js? I'm trying to learn Webpack and I know very little of what's going on here:
code:
var path = require('path');
var webpack = require('webpack');
var ExtractTextPlugin = require("extract-text-webpack-plugin");

module.exports = {
  entry: './main.js',
  output: {
    path: __dirname,
    filename: 'bundle.js'
  },
  module: {
    loaders: [
      {
        test: /.jsx?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        query: {
          presets: ['es2015', 'react']
        }
      },
      {
        test: /\.css$/,
        loader: ExtractTextPlugin.extract("style-loader", "css-loader"),
        include: [
          path.resolve(__dirname, "css"),
        ],
      }
    ]
  },
  plugins: [
        new ExtractTextPlugin("dongs.css")
    ]
}

Are you expecting webpack to create dongs.css? I think if you want to go this route, you'll need to have some separate step to compile this css file so it is at least available during your webpack bundling process. And then you need to have it being required in your js files.

# ? Jun 19, 2016 16:43

ModeSix: Mar 14, 2009

Skandranon posted:

Are you expecting webpack to create dongs.css? I think if you want to go this route, you'll need to have some separate step to compile this css file so it is at least available during your webpack bundling process. And then you need to have it being required in your js files.

So having read all this and understood the drawbacks of webpack. Why would I choose webpack over say a gulp process that minifies, concats and uglyfies both js and css?

Other than because hipster trending buzzword bullshit.

ModeSix fucked around with this message at 17:23 on Jun 19, 2016

# ? Jun 19, 2016 17:21

lunar detritus: May 6, 2009

ModeSix posted:

So having read all this and understood the drawbacks of webpack. Why would I choose webpack over say a gulp process that minifies, concats and uglyfies both js and css?

Other than because hipster trending buzzword bullshit.

Modules, but I guess there are plugins for that so... :shrug:

# ? Jun 19, 2016 17:37

Depressing Box: Jun 27, 2010; Half-price sideshow.

ModeSix posted:

So having read all this and understood the drawbacks of webpack. Why would I choose webpack over say a gulp process that minifies, concats and uglyfies both js and css?

Other than because hipster trending buzzword bullshit.

gmq posted:

Modules, but I guess there are plugins for that so...

Yeah, a lot of the immediate benefit is getting to use modules. In general, the closer your app is to a SPA the more useful Webpack becomes. Not that it's not useful otherwise, you just get more benefit from its more specialized features like code splitting and hot module replacement.

# ? Jun 19, 2016 18:34

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

ModeSix posted:

So having read all this and understood the drawbacks of webpack. Why would I choose webpack over say a gulp process that minifies, concats and uglyfies both js and css?

Other than because hipster trending buzzword bullshit.

You can do both. Webpack allows you to effectively bundle not just your JS files, but also your CSS and HTML (and some others) into a single JS file, in a CommonJS module format.

I'm still using a custom gulp process for bundling all my stuff, since it is already done and there isn't much immediate benefit to switching, but I am keeping an eye on Webpack for Angular2.

# ? Jun 19, 2016 18:41

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

ModeSix posted:

So having read all this and understood the drawbacks of webpack. Why would I choose webpack over say a gulp process that minifies, concats and uglyfies both js and css?

Other than because hipster trending buzzword bullshit.

Now that I understand that Nascar vehicles can't haul my RV, why would I use one over my truck?

Webpacks reason for existence is using (mainly NPM) modules in the browser. It conveniently has extension points so that you can use it to run your minification and other steps so you don't have to use more than one tool.

It also does static analysis of modules for tree shaking and a bunch of other stuff related to bundling.

As for why you should be using modules...well I'm not going to explain that because I'm on my phone. I'm sure Wikipedia has something on the point of libraries, modules, dependencies, etc.

If you're mainly making sites that use jquery, lodash, and a couple hundred lines of your own js then there's not much point.

The biggest project I'm working on now has 15 dependencies for deployment and 26 for development and a hundred internal modules.

# ? Jun 19, 2016 18:49

abraham linksys: Sep 6, 2010

I wrote a lil thing on Webpack a few weeks ago that may help if you're specifically wondering how it differs from, say, a Gulp/Browserify setup http://devlog.disco.zone/2016/06/01/webpack/

But yea Thermopyle covers it. The full ES6 module support coming in Webpack 2.0 should be very cool (and I'm excited that it apparently doesn't break the API very much!), bringing Webpack up to parity with Rollup.

# ? Jun 19, 2016 19:52

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

This is as much a back-end question as front-end, but what's good stuff to look into for deploying apps? I know there are more elegant solutions than check in to <source control of choice> on one machine then pull to the production machine, but I can't say I know where to start looking.

# ? Jun 21, 2016 14:50

HaB: Jan 5, 2001; What are the odds?

dupersaurus posted:

This is as much a back-end question as front-end, but what's good stuff to look into for deploying apps? I know there are more elegant solutions than check in to <source control of choice> on one machine then pull to the production machine, but I can't say I know where to start looking.

There's the whole Gulp/Grunt/Webpack minify/uglify/consolidate tool chain. Basically it adds a Build step to your process, just like a compiled language, only instead of compiling - it's processing sass into css, minifying javascript, maybe consolidating everything into a single file, versioning files, etc. etc.

Fair warning- that's nearly as deep of a rabbit hole as javascript frameworks are these days. So I would get an idea of exactly what you'd like to deploy and then decide from there how to apply that toolchain to get what you want.

# ? Jun 21, 2016 14:57

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

I've been using gulp and I'm starting to look into webpack, so I've got that step. The part I'm wondering about is how do you go from there to getting everything onto your production server. For example: my ward at work is an unholy mess of vanilla PHP and different flavors of JS, and pushing it is just checking in and merging into successive perforce branches until you get to live. So if I wanted to take the opportunity of an upcoming server rebuild to rethink how we do things, are there options out there?

# ? Jun 21, 2016 15:14

YO MAMA HEAD: Sep 11, 2007

We're a tiny shop in a similar boat with a lot of small projects and I was able to move pretty painlessly to CI with Bamboo (we may switch to Jenkins eventually). Commits get composer/NPM/bower/gulp/grunt install'd (depending on the project), results get saved as artifacts. Deployment rsyncs the artifacts twice� local-to-remote to a temporary folder on the staging/production server and then remote-to-remote to get directories to the right place in docroot. DB stuff is still different for each project and the one thing that needs the most attention, but our CodeIgniter and Laravel projects get migrations run automatically.

We supposedly hired a devops contractor to help us look at Ansible or Saltstack or some other deployment solution but he sorta disappeared. In any case we have a lot of projects sharing one or two CentOS server and a few of our virtual environments are Ubuntu (homestead and trellis) so we couldn't be handling package mangement or anything in deployment.

This is far from the best or most state-of-the-art way of doing things, but it was a reasonable second step for us after finally starting to use DVCS.

# ? Jun 21, 2016 15:28

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I've been considering dokku for an upcoming project. I've always really liked how Heroku lets you just git push your project and its automatically deployed, and dokku lets you do that with your own servers.

# ? Jun 21, 2016 16:37

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

dupersaurus posted:

I've been using gulp and I'm starting to look into webpack, so I've got that step. The part I'm wondering about is how do you go from there to getting everything onto your production server. For example: my ward at work is an unholy mess of vanilla PHP and different flavors of JS, and pushing it is just checking in and merging into successive perforce branches until you get to live. So if I wanted to take the opportunity of an upcoming server rebuild to rethink how we do things, are there options out there?

For font-end SPA type stuff where the "deployment" is new JS / CSS bundles and an updated index.html with the new chunkhash(es) for said .js and .css files, I have a Makefile that has a bunch of rsync commands in it like so:

code:

rsync_upload: publish
rsync -e "ssh -p $(SSH_PORT)" --exclude-from '$(EXCLUDE_FILE)' -P -rvz 
      --delete $(PRODDIR)/ $(SSH_USER)@$(SSH_HOST):$(SSH_TARGET_DIR) --cvs-exclude

Which runs webpack with it's production config, then puts things on the server.

Lumpy fucked around with this message at 17:01 on Jun 21, 2016

# ? Jun 21, 2016 16:59

Urit: Oct 22, 2010

Ansible is real nice for this if you don't want to install an agent/central master server, your build box if you have one can do the pushes if needed, or the dev that builds it can do the push from their local machine. I picked up Ansible from 0 knowledge (though I already had knowledge of Chef and Saltstack) in about 2 days so it's super easy to learn IMO. Also re: Package management for deb/rpm etc.: check out FPM if you want to try making debs and rpms with the same contents easily.

# ? Jun 21, 2016 17:37

Plavski: Feb 1, 2006; I could be a revolutionary

For those interested in Aurelia, here's a nice rundown of Aurelia vs Angular: https://www.sitepoint.com/aurelia-vs-angular-feature-comparison/

# ? Jun 22, 2016 22:44

consensual poster: Sep 1, 2009

Plavski posted:

For those interested in Aurelia, here's a nice rundown of Aurelia vs Angular: https://www.sitepoint.com/aurelia-vs-angular-feature-comparison/

While I'm excited about Aurelia and happy to see that Angular 1 is on its way out, that article is framework cheer-leading of the worst sort. Many of the points he makes about Angular are flat-out false, such as:

quote:

Angular�s change detection relied on a �digest cycle�. Essentially, AngularJS would define a time interval, and at the end of each interval, it would �digest� all of the changes that happened since the last digest. This happened multiple times per second.

Digest cycles are triggered by some event. Angular does not use polling for change detection. This is Angular 101 poo poo and it shows that the author has no interest in giving an accurate overview of the differences between the frameworks. There are a bunch of other falsities and half-truths, but it's not worth getting into them all.

Aside from that, the article is really light on details. Even if he got poo poo right, it would still be largely worthless IMO.

In other Aurelia news, they announced the Release Candidate today: http://blog.durandal.io/2016/06/22/the-aurelia-release-candidate-is-here-2/

consensual poster fucked around with this message at 00:37 on Jun 23, 2016

# ? Jun 23, 2016 00:33

Xik: Mar 10, 2011; Dinosaur Gum

Perfectly Cromulent posted:

happy to see that Angular 1 is on its way out

May I ask why?

It's a genuine question, I'm about to spend a bunch of effort learning (and then using) angular. Workplace has decided to use angular as the front-end for a bunch of app rewrites that will be happening over the next couple years.

# ? Jun 25, 2016 08:00

Ahz: Jun 17, 2001; PUT MY CART BACK? I'M BETTER THAN THAT AND YOU! WHERE IS MY BUTLER?!

Xik posted:

May I ask why?

It's a genuine question, I'm about to spend a bunch of effort learning (and then using) angular. Workplace has decided to use angular as the front-end for a bunch of app rewrites that will be happening over the next couple years.

I like Angular. I don't think it's that difficult and its nice to have an all in one ecosytem for an app. If I were writing an app from scratch today, I wouldn't use it primarily for the digest cycle and its generally poor performance. It works fine in the apps I built, but its easy to fall in and out of the digest cycle and scope from other frameworks or tech, like D3 or 3rd party tools like Telerik controls etc.

Don't get me wrong, the performance is ok, but often I find Angular prefers to watch everything and it adds up. I know I can manually take watches off or rebind / unbind things, but its a hassle to manage that when often I don't need or care about 2 way binding. 1 way is enough 99% of the time and 2 way is a special case.

Then theres the 'magic' in it which can be annoying to debug, even when paired with UIs like Angular Material, I often want fine grained control of my UI and I can't have it without major hacks. Maybe its better with things like Typescript or ES6, but even with named controller scope, I often get into pass by value / reference issues with Angular when it's not clear what its doing. angular.forEach is copied by value, dontchya know??? but everything in your services is a singleton. Not bad to work with once you know it, and I would be fine with everything if it were faster, but the speed is an issue.

# ? Jun 25, 2016 16:06

Summit: Mar 6, 2004; David wanted you to have this.

Angular performance is a concern for complex web apps (like a chat room) but for the vast majority of simple web sites it is more than up to the task. In an enterprise where the business people just want a spruced up CRUD site I think it's a great fit.

# ? Jun 25, 2016 16:47

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Xik posted:

May I ask why?

It's a genuine question, I'm about to spend a bunch of effort learning (and then using) angular. Workplace has decided to use angular as the front-end for a bunch of app rewrites that will be happening over the next couple years.

It's only on the way out in the sense that Angular 2 is out and looks to be an even better framework to use, if you like Angular 1. There is also a smooth upgrade path from Angular 1, and it is getting smoother as time goes on. The Angular 1 branch is going to be supported for 2 years after Angular 2 is fully out, and they may even extend that if there is enough demand.

# ? Jun 25, 2016 17:20

consensual poster: Sep 1, 2009

Xik posted:

May I ask why?

It's a genuine question, I'm about to spend a bunch of effort learning (and then using) angular. Workplace has decided to use angular as the front-end for a bunch of app rewrites that will be happening over the next couple years.

Sorry for not replying to this earlier.

I have used Angular a lot over the past 3 years, enough so that I have a good understanding of about 90% of the "magic" that makes Angular work. For the most part, I like it and find that it is filled with quite a lot of good ideas (as well as some bad). They've also done a good job of upgrading the framework as time as gone on. Angular 1.5 is a really big jump forward in developer-friendliness for the framework, IMO.

That being said, there are a bunch of things about it that are bad or outdated. In no particular order:

You have to use a bunch of Angular-specific stuff for things that are now standard (e.g. Angular's module system and the $q service for promises). Not Angular's fault, really, since that stuff wasn't standard at the time, but you're still stuck with it.
Only designed to work against the DOM. This makes isomorphic/universal JS apps or targeting other platforms (like mobile devices) with Angular very difficult and complex.
You have to learn a lot of framework-specific Angular-isms. There are always framework-specific things one has to learn, but Angular seems especially bad in this regard. This wouldn't be so bad if it weren't for the fact that...
The Documentation (still!) sucks. Not the API Reference, which is fine, but the Developer Guide. It is confusing, poorly written, and lags behind community-established best practices in its advice. Even the new stuff, like the Components section, is bad. I understand Angular Components pretty well and I come away from that document confused.
So much "magic". A beginner is almost never told about how Angular actually works because the topic is simply too big and complex for a new developer to grasp both the framework API and even an overview of the Angular internals. It is all going to seem like magic. This leads to developers creating erroneous mental models of how things are working, which leads to bugs and deep confusion when that mental model is shown to be wrong. I've seen it so many times. You end up having to unlearn a bunch of stuff you thought you understood and replacing it with a lot of deep technical knowledge about Angular internals. Compare this to learning React + Redux where I spent a couple of hours on it and I not only felt like I had a good grasp on how to develop an app, but could almost re-write a half-assed implementation of the framework itself because how to develop with it is tied to understanding how it works.
Angular's change detection prioritizes simplicity, flexibility, and correctness over speed. This is not to say that it is slow, just that there are pretty hard limits on what can be done to make it fast in complex scenarios that have lots of expressions being watched. The change detection algorithm scales linearly with the number of watched expressions (O(n)) because the possible existence of two way data bindings between controllers, directives, and components means that a change in data in one place could possibly result in a change anywhere else in the application. Thus, EVERY watched expression must be evaluated during every turn of the digest cycle to ensure that all changes are detected. Furthermore, since watched expressions can modify values, the digest cycle has to run (at least) once more to make sure that a value of a watched expression didn't change in the previous cycle. That means that, for example, if you have 1000 watchers in your app, the digest cycle has to run at least 2000 checks every time it is triggered. The only way to make your application significantly faster is to reduce the number of watched expressions (a bit of an oversimplification, but mostly true).

# ? Jun 29, 2016 00:35

lunar detritus: May 6, 2009

Skandranon posted:

It's only on the way out in the sense that Angular 2 is out and looks to be an even better framework to use, if you like Angular 1. There is also a smooth upgrade path from Angular 1, and it is getting smoother as time goes on. The Angular 1 branch is going to be supported for 2 years after Angular 2 is fully out, and they may even extend that if there is enough demand.

There's a smooth upgrade path only if you used Angular 1 for a SPA. Full stack apps (Rails/Django/Whatever server-rendered views + Angular) are hosed.

# ? Jun 29, 2016 01:40

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

gmq posted:

There's a smooth upgrade path only if you used Angular 1 for a SPA. Full stack apps (Rails/Django/Whatever server-rendered views + Angular) are hosed.

How is Angular2 more of a problem doing this than Angular1? One of the big features of Angular2 is Angular Universal, which is all about doing server side rendering of Angular2 apps.

# ? Jun 29, 2016 04:24

lunar detritus: May 6, 2009

Skandranon posted:

How is Angular2 more of a problem doing this than Angular1? One of the big features of Angular2 is Angular Universal, which is all about doing server side rendering of Angular2 apps.

Angular Universal looks great but changing the entire infrastructure of your legacy rails app just to add support for it seems unrealistic. There are plans to support other languages / frameworks but nothing yet.

I encountered two problems when exploring upgrading to Angular 2 (and if any of you has a clean solution for them I'd very thankful):

You can't use your server side views directly anymore, you need to convert them to Angular 2 components and load the templates from there. Angular 1 allowed me to put an ng-app to bootstrap the app, directives where needed, etc. Angular 1 only needed templates for its directives, everything else came already rendered. Also, bye server-side routing unless you mount a different root component for each of your pages.
Then I thought, maybe I can hack it and run multiple angular 2 apps, one for each component I wanted to use. One dynamic dropdowns, one for carousels, etc. Very messy but it would help me upgrade bit by bit. But, it's not possible, Angular 2 bootstrap's process only runs on the first element that matches its selector. So, if a page has two dropdowns whoops, it won't work.

Both problems can be worked around but by then the effort to achieve a working (but ugly) solution just wasn't worth it. Even the Angular 2 team says "Nope, SPAs/AU or get out":

Angular Team Member posted:

server side rendering is a huge part of angular2, today with angular/universal and soon with any number of other languages (drupal, .net, etc). that said, our vision is more that you'd write an angular application (that is, not separate client and server application) and bootstrap it server side, and then boot the SPA to take over.

https://github.com/angular/angular/issues/1858#issuecomment-208001943

Angular Team Member posted:

I don't think this is going to be supported, as angular is primarily designed as a single-page application framework, and the intent is angular should control the content inside the root app element.

That said - you should have a look at the https://github.com/angular/universal project, which enables pre-rendering of angular apps on the server side.

https://github.com/angular/angular/issues/6194#issuecomment-168246552

I mean, I really like Angular 2 but I think that using it for anything but a SPA is looking for problems. Maybe my use case of using Angular as dynamic layer on top of an app is rare? I'm crossing my fingers to get a working AU solution soon but for now I ended up migrating to Angular 1.5 + Typescript. A lot of the niceties of Angular 2 without having to touch anything else.

# ? Jun 29, 2016 06:22

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 22:39

HaB: Jan 5, 2001; What are the odds?

Anyone have any experience disabling Picture in Picture playback on Safari/iOS 9.2+ ?

the property is now public in Swift/Obj-C, but I'm wondering if there's a way to toggle it from javascript.

Thanks.

# ? Jul 11, 2016 20:00

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »