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

Stoph: Mar 19, 2006; Give a hug - save a life.

Marionette seems to be more popular but at work we use Chaplin with Backbone.js:

https://github.com/chaplinjs/chaplin

# ¿ Sep 20, 2013 00:28

Adbot: ADBOT LOVES YOU

# ¿ Apr 19, 2024 05:35

Stoph: Mar 19, 2006; Give a hug - save a life.

blugbee posted:

Assuming you have devs who are equally competent in both server side (Rails/Django etc.) frameworks and JS based ones what are the major factors that would lead someone to choose between a server side or JS framework? Am I wrong in thinking that JS based frameworks are unsuited for projects with performance and security based requirements?

You need both. JavaScript frameworks don't replace Rails/Django, they replace jQuery spaghetti. Your application is not less secure because you organize your client side code better.

# ¿ Sep 20, 2013 16:57

Stoph: Mar 19, 2006; Give a hug - save a life.

wretched_gavek posted:

The idea was to take the form values from the html and update the .json document on the server. Right now it is pulling from the document successfully but the ".post" function is not writing the values back to the document. I'm a bit over my head and fairly certain i'm missing a few (or a lot) of vital steps.

What is the issue here?

Forgive me if this is too elementary, but you need a server-side language like PHP to process your form submission. You can't just post data to a file and expect the file contents to change.

# ¿ Dec 6, 2013 09:01

Stoph: Mar 19, 2006; Give a hug - save a life.

Parse (https://parse.com/) and Firebase (https://www.firebase.com/) are hosted backends for a "static files application". Perhaps you should give them a look.

# ¿ Dec 10, 2013 17:59

Stoph: Mar 19, 2006; Give a hug - save a life.

The Merkinman posted:

So I'm starting a new project from scratch using Foundation and SASS. Should my entire site be in app.css?

Yeah, your entire stylesheet for the site should be in a single file when served to the browser. However, there is a limit on selectors in IE, so if you run a huge site with a lot of stylesheet rules, then you add a tool like Bless to split the stylesheet into two different files:

http://blesscss.com/

# ¿ Aug 10, 2014 04:17

Stoph: Mar 19, 2006; Give a hug - save a life.

streetlamp posted:

Gots a question for you nerds about building a pretty simple app and what you would recommend for it (frameworks or whatever).

Currently have a site with some lists of things to do in the city, like a itineraries and stuff. I can retrieve all these posts via a JSON API. What I would like to do now is build a simple app that just fetches data from this API and now its on your phone, ta-da. Not dependent on having internet and can just resync and update when you do.

I know 0 about any native app development, I do have a decent set of JS skills but little experience with anything like Angular, Backbone, etc. What do?

You can look at Titanium and Alloy application development. Great for quick throwaway or proof of concept apps. It uses JavaScript.

# ¿ Sep 26, 2014 02:12

Stoph: Mar 19, 2006; Give a hug - save a life.

Wheany posted:

This wouldn't be that bad it there was actual documentation for RSVP.Promise.all, but there isn't. Instead, if you look at http://emberjs.com/api/classes/RSVP.Promise.html, you may find the last code example before the method listing, titled "Unlike callbacks, promises are great composable primitives.", where the code example nonchalantly shows that the callback given to "then" function gets an array of values, and not for example the values themselves as arguments.

In their defense, promises are pretty much part of the language now. Some promise libraries have helpers to mitigate that issue, for example Bluebird has Promise.prototype.spread:

https://github.com/petkaantonov/bluebird/blob/master/API.md#spreadfunction-fulfilledhandler--function-rejectedhandler----promise

(promises can't resolve to more than 1 argument by default)

# ¿ Oct 3, 2014 15:28

Stoph: Mar 19, 2006; Give a hug - save a life.

Browserify is the current "state of the art" imho, but it requires you to adopt some unholy tool chain of grunt scripts, or gulp scripts, or who knows what is in vogue...

RequireJS is nice because it doesn't have a build step until you release to production...

# ¿ Oct 18, 2014 22:18

Stoph: Mar 19, 2006; Give a hug - save a life.

caiman posted:

This is less a "newbie" question and more a "I have no idea what this poo poo is" question. How does the database fit into this whole front-end framework thing? All the overviews I read about AngularJS (for instance) keep mentionaing JSON files. But where does, say, a mysql database fit into the picture? Do these frameworks function in lieu of a traditional relational database? Or is getting the database formatted into JSON data just one of the back-end steps required for these frameworks?

It doesn't matter! It could be a static JSON file stored on a hard drive, or a REST server that queries a database, then transforms the output into JSON format. The client only cares if the JSON is well-formed and contains the necessary data.

quote:

Or is getting the database formatted into JSON data just one of the back-end steps required for these frameworks?

Usually there is a whole separate framework (like Ruby on Rails or Django or Laravel) that deals with generating API results.

# ¿ Jan 9, 2015 18:08

Stoph: Mar 19, 2006; Give a hug - save a life.

Funking Giblet posted:

I just dropped this!
https://github.com/gibletto/ItDoesFuckingNothing

Sorry, it looks like you're infringing on the intellectual property of Vanilla JS.

http://vanilla-js.com/

# ¿ Jan 27, 2015 16:36

Stoph: Mar 19, 2006; Give a hug - save a life.

Pollyanna posted:

Anyone here use gulp? I'm trying to think of a way to make using it a little easier for me to handle.

As I understand it, gulp makes use of streams and piping to build/concatenate and watch files. The basic idea is that a source file is input, several transforms are placed upon it, and a finalized source file is output. For example, if I wanted to take a file app/main.js, run Browserify on it, Uglify it, then output it as bundle.js to a dist/src directory, it'd look something like this

Your response to writing a 14-line Gulpfile is to start designing a new programming language. Can you understand why your employer and/or coworkers would be a little worried about this?

# ¿ Feb 5, 2015 20:38

Stoph: Mar 19, 2006; Give a hug - save a life.

I like JSX. I can give my components to front-end web developers who aren't comfortable with much more than HTML/CSS and they "get it".

I compile on-the-fly with RequireJS and JSX loader plugin so there is no build step in development.

I want to switch to Browserify but this way is just too easy.

# ¿ Feb 12, 2015 03:10

Stoph: Mar 19, 2006; Give a hug - save a life.

I feel the same way man, and it seems like you're trying out all the options that made me hate JavaScript testing. Perhaps you can set up a CI server to run CasperJS integration tests and let me know how you feel about those as well. I like integration tests because you don't have to convince any of the assholes you work with to write them - you can just have your robot ping them when they gently caress up the build.

# ¿ Mar 17, 2015 15:59

Stoph: Mar 19, 2006; Give a hug - save a life.

geetee posted:

Webpack is awesome, but I want to blow my brains out because my coworker is a neanderthal. He's making GBS threads all over my parade because he's content with the JavaScript he wrote 15 years ago. For context, this guy still runs Windows XP by choice (and considers it the gold standard), and rather than create a git branch, he'll just copy the directory.

This is stuff the CTO/VP Engineering/Lead Developer should be enforcing... If your coworker is a neanderthal, then leave him be or convince your company to put the processes in place fix it.

# ¿ Apr 1, 2015 18:34

Stoph: Mar 19, 2006; Give a hug - save a life.

ambushsabre posted:

I just want to chime in on the frontend interviewing talk, especially with javascript. Here's my goto question (I'm a team lead where my team exclusively does js pretty much):

"You have a page with a button on it. When the page loads, make an api request to example.com/api/whatever?. When you have both the result of the api request and the button has been pressed (these can happen in any order), navigate to google.com."

I like this one because it really lets me know if they've worked in javascript before. If they have, I'm going to hear the word 'callback' at least once, something about ajax, and probably window.location.href. It also lets them tell me about setting a variable to keep track of the states of both these things which is some pretty simple logic, as well as being relatively real-world. I dunno it's done a good job of filtering out the bad people so far.

I'd be very happy to hear them mention Promise.all

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

# ¿ Apr 8, 2015 17:36

Stoph: Mar 19, 2006; Give a hug - save a life.

PlaneGuy posted:

edit: another reason to be aware of your dependencies... if your dependency doesn't put a fixed version for its dependencies, you might actually get wildly different versions amongst devs

That's a good reason to use npm shrinkwrap.

# ¿ Apr 9, 2015 22:24

Stoph: Mar 19, 2006; Give a hug - save a life.

The best part is that many Google engineers have expressed desire to use React.js instead of Angular but they can't because of insane bullshit like the React.js PATENTS file:

https://github.com/facebook/react/pull/3554

One commentor mentioned their company's lawyers cleared that the code is licensed as BSD so they could just fork React.js and remove the file... :psyduck:

# ¿ Apr 10, 2015 18:06

Stoph: Mar 19, 2006; Give a hug - save a life.

yoyomama posted:

I was wondering if there's anyone that can point me to a resource that explains how to have a React component listen to changes in an input field that isn't rendered by React. I'm using React for one part of a web app I'm making, and getting it to work with the rest of my code has been a challenge (and facebook's docs don't help at all).

If you want to do crappy legacy hacks, the state API is the way to go. It makes me feel like a "bad programmer" sometimes but I create tons of crap like this:

code:

    var $ = require('jquery');
    var React = require('react');
    var uuid = require('uuid');

    module.exports = React.createClass({
        // Good to have display name on your components for debugging
        displayName: 'Test',
        getInitialState: function () {
            // Need to define an initial state since we are going to use state
            return {
                otherValue: ''
            };
        },
        componentDidMount: function () {
            var $otherInput = $('.other-input').eq(0);

            // This ID variable is to compensate for jQuery's crappy unbinding
            // API, you could probably use Math.random() instead of a uuid
            var id = uuid.v4();
            $otherInput.on('change.' + uuid, function () {
                this.setState({
                    otherValue: $otherInput.val()
                });
            });

            this.setState({
                otherId: id,
                otherValue: $otherInput.val()
            });
        },
        componentWillUnmount: function () {
            // Need to clean up our event handler
            this.state.$otherInput.off('change.' + this.state.otherId);
        },
        render: function () {
            return (
                <input value={ this.state.otherValue } />
            );
        }
    });

This is not React best practices but sometimes you just need to Get poo poo Done. Then later when I have time I drop the jQuery soup and upgrade it to pure React+Flux style.

bartkusa posted:

Have a non-React piece of code listen to the non-React input, and feed the value to the React component as a prop.

React components shouldn't listen to anything except props.

This is the better way.

# ¿ Apr 23, 2015 15:43

Stoph: Mar 19, 2006; Give a hug - save a life.

Helicity posted:

Interesting stuff, and super glad they included a "Why?" section on that page. Thanks for the info.

This page describes doing something similar with your own components:

http://facebook.github.io/react/tips/props-in-getInitialState-as-anti-pattern.html

This is probably where Lumpy got the "initialValue" terminology from.

# ¿ Apr 30, 2015 17:54

Stoph: Mar 19, 2006; Give a hug - save a life.

It helps if you think in terms of understanding the ES6 promise spec (this stuff is core JavaScript now) and treat the different libraries out there as implementation details. Here is some documentation:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

You almost always want to use the foolproof way (new Promise) like this when wrapping/promisifying callback APIs manually:

code:

var serviceMethod = function () {
    return new Promise(function (resolve, reject) {
        doAsyncThing(function (err, data) {
            if (err) {
                return reject(err);
            }
            resolve(data);
        })
    });
};

Or even better, libraries like Bluebird add functions like Promise.promisify.

# ¿ May 13, 2015 18:08

Stoph: Mar 19, 2006; Give a hug - save a life.

Helicity posted:

Speaking of, does anyone like a specific library for replacing jQuery's $.ajax and $.getJSON?

window.fetch is coming soon to browsers near you. There's a decent polyfill but it might be easier just to use XHR directly until all the dependencies (like window.Promise) are standard too.

# ¿ May 14, 2015 20:09

Stoph: Mar 19, 2006; Give a hug - save a life.

Soup in a Bag posted:

Should there be one Concert component that renders differently based on some passed-in value? Or should there be two components like Concert and ConcertDetail and those will be backed by the same Rails model?

Basically, what's the React way to handle one model that needs to be rendered in different ways?

You should make two separate components.

# ¿ Jun 2, 2015 06:29

Stoph: Mar 19, 2006; Give a hug - save a life.

Ochowie posted:

So in the course of looking at delving into React I see that almost all of the examples out there use node.js as the backend routing framework. Coming from Angular which has the routing built into the client side code I'm not sure what the equivalent (if any) would be for React.

I think you're confused as gently caress. You might want to ask more clarifying questions because I'm not sure how to approach this.

The backend/server does not necessarily have to have anything to do with React.js - it's just like AngularJS in that regard. I use it with PHP as the backend, for example.

# ¿ Jun 5, 2015 23:44

Stoph: Mar 19, 2006; Give a hug - save a life.

Thermopyle posted:

I just create them. I haven't really understood the point of using a library for forms, but that's probably more because I'm dumb rather than there not being an actual point.

I do the same by maintaining a basic data structure like this consistently on all my forms.

code:

{
    inputs: {
        key: val
    },
    errors: {
        key: [val]
    }
}

Any action in my store can update this map to reflect the current state of the form and the UI will re-render. I wire it all together manually without libraries but I'd love to figure out "the right way".

# ¿ Oct 31, 2015 05:42

Stoph: Mar 19, 2006; Give a hug - save a life.

So what is the answer when it comes to widget state like accordions or tooltips or confirm dialogs or etc.?

# ¿ Nov 21, 2015 02:52

Stoph: Mar 19, 2006; Give a hug - save a life.

EkardNT posted:

How would you handle purely widget-related/UI state in a redux application? I'm talking about stuff like dropdown open/closed, selected tab, etc. It gets very cumbersome very fast to make a reducer for every single instance of a widget in your application...

I asked this one a couple pages back

Stoph posted:

So what is the answer when it comes to widget state like accordions or tooltips or confirm dialogs or etc.?

# ¿ Dec 15, 2015 19:41

Stoph: Mar 19, 2006; Give a hug - save a life.

caiman posted:

Are there any advantages of using something like MongoDB instead of plain .json files for storing and retrieving simple styling and text content data?

Try searching Google with some combination of terms like advantages and disadvantages of files over databases/databases over files and let me know if you have any questions...

This is a vague question.

# ¿ Jan 5, 2016 21:32

Stoph: Mar 19, 2006; Give a hug - save a life.

It's not too hard to turn a regular website into an "SPA".

If you're willing to be ghetto you can Ajax in entire HTML pages ala "turbolinks" (the Rails JavaScript library which implements this).

Then you can share data between pages easier.

# ¿ Jan 31, 2016 21:12

Stoph: Mar 19, 2006; Give a hug - save a life.

Helicity posted:

When you're shooting for 1second load times, especially with mobile, you basically can't use any of these frameworks.

I agree with much of what you said but if you're optimizing for load time, it's well-known in the React.js world to pre-render the page and send down the full HTML markup to the client. That gets you your 1 second load time. Once the client renders, it's essentially a no-op to the DOM because the actual DOM already matches the virtual DOM.

# ¿ Feb 1, 2016 05:59

Stoph: Mar 19, 2006; Give a hug - save a life.

Maluco Marinero posted:

Also, you can render with React without all the React tags if you wish. That leaves the door open while still getting client performance.

Gul Banana posted:

what do you mean by the term "decorator" here?

I think we are referring to the difference between renderComponentToString and renderComponentToStaticMarkup:

https://github.com/facebook/react/issues/1296

I would be interested in reading a blog post with benchmarks on this... I would assume (without any evidence to back this up, mind you) that the decorators make the page load faster because you don't have to touch the DOM as much during page load. But then again, that assumes you're using React.js and perhaps eliminating it is the true speed-up.

# ¿ Feb 2, 2016 00:17

Stoph: Mar 19, 2006; Give a hug - save a life.

You should statically analyze your code style and accept nothing less than 100% adherence with automated tools handling enforcement.

If you do that, it's trivial to change coding style between projects.

# ¿ Feb 13, 2016 01:33

Stoph: Mar 19, 2006; Give a hug - save a life.

Skandranon posted:

You don't even really need 1.5 to do Angular properly, you can accomplish pretty much everything important in 1.3, which is when they introduced bindToController. Everything after that is just gravy.

I'm forced to stay on 1.3 at work and my strategy is to make literally everything a directive with isolate scope and bindToController true.

# ¿ Feb 22, 2016 16:46

Stoph: Mar 19, 2006; Give a hug - save a life.

When I used to use GWT at work it would compile the entire project into an HTML file. It was actually super convenient.

# ¿ May 28, 2016 18:57

Stoph: Mar 19, 2006; Give a hug - save a life.

N.Z.'s Champion posted:

it's ok, but it's slowly dying. here's a bower dev DeSandro

bower seem to not letting their ego get in the way very much. good on them

https://github.com/bower/bower/issues/2298

# ¿ Jun 10, 2016 04:34

Adbot: ADBOT LOVES YOU

# ¿ Apr 19, 2024 05:35

Stoph: Mar 19, 2006; Give a hug - save a life.

Then why don't they loving use Apache 2.0. It's a clusterfuck to be honest and a shame because they have community mindshare.

# ¿ Jul 18, 2016 23:59

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