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

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Sagacity posted:

(i.e. it's still faster to render a huge grid just by concatenating strings instead of doing it using nested templates)

I would expect that to generally be the case, really. At the end of the day you have to get the browser to create a bunch of nodes and insert them in the tree, and the parser is pretty much the fastest way to do that in a modern browser. Anything on top of that is extra work to be done, ideally in exchange for some better ergonomics. (innerHTML is generally faster than DOM calls, too.) String concatenation is O(1) on all remotely modern JS engines, so it's going to be really hard to beat. It also helps that innerHTML and friends have been optimized to hell and back because of how widely they're used, to the point of browsers reaching a gentlemen's agreement to all violate the standard in a certain way and avoid node allocation in one common circumstance.

Sometimes frameworks can, through those ergonomics, make optimizations feasible that weren't before, like React's diffing, but for initial subtree creation I have trouble imagining a way to beat the parser.

Maluco Marinero posted:

Yeah. To be honest that post is me about 2 months ago. We changed core functionality to React js and have not looked back since. We pulled page loads down from 35seconds in large data sets, down to 3 seconds, and ended up being able to easily augment components to start reusing DOM elements in an infinite scrolling setup, for even greater mobile efficiency gains.

As an aside, I've been doing some pure react work lately and really enjoying it. Couple it with some extra modules like director for page routing, and precompiled jade templates and you end up with this super maintainable structure that runs like lightning.

I shared this with the React team, and they were very smile. It's exactly the experience they want developers to have (though they don't care very much about competition with Angular or other frameworks), and it's great to hear you're enjoying it.

quote:

Back end frameworks that are slow, like Django and Ruby, can at least be scaled by throwing hardware at the problem, at least to a point. You don't have that option on the client side, especially if you're involving mobile, so the only sustainable option is something that's fast by default.

Twitter and Instagram and probably other sites throw hardware at some of these problems by doing rendering on the server side in some cases like initial load, because latency tends to be a bigger issue than the bandwidth loss from sending more verbosely encoded data. Twitter has a bunch of mustache libraries for this (Hogan!), and Instagram uses React that way IIRC.

# ¿ Mar 21, 2014 16:24

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 16:12

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

MrDoDo posted:

SQLite?

Yeah, if you can't get away with just serializing objects as JSON, sqlite is the go-to choice these days. If you don't need the relational stuff, leveldb is pretty straightforward and pleasingly fast.

# ¿ Mar 27, 2014 01:47

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Greve posted:

http://jsfiddle.net/fimiak/QSu2p/

This is why I think angular will succeed in the long term, or at least will never be dropped by Google. Its community is growing exponentially. An ng conference for Europe in Paris with all of the top guys was just announced.

http://jsfiddle.net/nt5GA/1/embedded/result/
http://jsfiddle.net/nt5GA/2/embedded/result/

Is Angular used on anything public-facing or mission critical by Google? The better determinant of how much they'll invest is "how hard is it for them to get away from it/how much of their poo poo will break if they don't update it" not "how many people on the internet wanted to know what it was". I don't think it's really feasible to predict how companies will continue to invest, but aligning with their amount of self-interest is the best approximation I've found.

# ¿ Apr 10, 2014 17:58

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Corla Plankun posted:

This is a really dumb question but I am having a hard time figuring out how to approach finding a solution.

How do I get local information onto a website in real(ish)* time?

A toy example: I have an ubuntu machine that is currently hosting the default "It works!" apache homepage; the same machine is also running a python script that communicates with an external temperature sensor. I want to host a website that updates the temperature as it changes (without refreshing). How do I bridge the information from python (or some other language if it is more convenient, idgaf) to a website?

I am pretty sure the answer is some kind of javascript library, but I can't figure out a concise way to describe (and then google) this problem.

_{*500ms of latency on a LAN would be ideal but longer turnaround times would not be the end of the world.}

http://socket.io/

https://github.com/abourget/gevent-socketio purports to be for Python, but I haven't used it. The LearnBoost guys are pretty smart, though, so I'd be optimistic.

# ¿ Apr 16, 2014 22:46

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

ManoliIsFat posted:

Then again, I don't know your exact requirements, so maybe you do need socket.io for the data to be pushed from the server instead of you polling it constantly.

socket.io can use longpoll or Flash or a bunch of transports, IIRC. It really was a wonderful "just works" experience across N browsers and whatnot when I last used it (~2 years ago).

# ¿ Apr 17, 2014 00:11

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Thermopyle posted:

Is anyone interested in seeing that?

The React team is.

# ¿ May 15, 2014 03:11

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Lumpy posted:

My favorite is the React-Flux-TodoMVC example (http://facebook.github.io/react/docs/flux-todo-list.html) Paragraph 2 is basically "grab react-boilerplate, and then do all the npm install crap to get started." Paragraph 3 is "Oh, btw, the settings in the boilerplate package.json file all need to be changed to work with this tutorial. Look at our package.json file and figure it out."

I agree, that's pretty gross. I'll bring it up with the team.

# ¿ Jun 21, 2014 21:24

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Maluco Marinero posted:

Haha yep. Just for a bit of reference for React devs, the way React renders is a lot more straightforward than you think.

Of course there's a decent amount going on in the internals, but you can simplify it down go this:

Render cycle is done in JavaScript, and each component is given a key, this is either a number when you put in component children as arguments, or a string key when you use the property 'key' on that component. This key is how React finds the element in the real DOM, which you'll see in the only proprietary tag React uses, 'data-react-id'.

When the render cycle is done, it's diffed against the last render cycle, to see what changes need to be made. In the above case it would see that the only difference is that the {style: width: '65%'} property has changed.

With that information React does the DOM operations in as simple a way as it can. Using keys and what not to reuse elements effectively.

If a key needed to be moved, it can do it without having to rebuild the entire DOM element because it knows where it was and where it needs to go. In the case of the simple style tag, the resulting Dom operation is basically equivalent to:
code:
document.querySelector('.progress-bar').style.width = '65%';
---

The main thing to remember with the React model is that it is NOT magical, it is well thought out and detailed but not to the point of a magical black box. You have good control over rendering using keys and, in rare cases, the shouldComponentUpdate method.

This means that if something works in standard HTML,CSS and a little bit of direct JavaScript, the same concepts still apply to React, you're just doing less bookkeeping.

This is great.

# ¿ Jul 9, 2014 03:44

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Lumpy posted:

If you can/ don't mind saying, what do you do at Facebook? Understandable if you don't or can't answer

I'm an Engineering Director. I ran Android/iOS/mobile-web engineering for a year and a half while we were rebooting it, and most recently I've been working with our teams doing open source stuff to help them be successful. Not sure what I'm going to work on next!

# ¿ Jul 10, 2014 17:58

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Tres Burritos posted:

Has anyone seen the Kickstarter for "black-tie"? Apparently it's the same dude that made fontawesome so I'd like to send some money his way, but $90 bucks for some icons? I dunno about that.

Only $30 for a single weight, it looks like. Or you could just pledge $1/$5/$10 and count toward the 3000-backer Font Awesome improvement threshold.

# ¿ Jul 14, 2014 15:47

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Pollyanna posted:

What the hell do I choose

Problem is which one to choose

You don't have to pick the best one. Pick something with an example that's close to what you want to do, or which feels comfortable to you. Don't jump ship because you hit one problem that another framework might address better. Learn by finding the limits of the tool, stretching it, and then looking how to bridge it to other tools. If you choose anything that has more than 100 users, it'll be good enough to make your project possible. Start working.

quote:

I'm starting with just reviewing how JS implements MVC/MVVM in general.

JS doesn't "implement MVC/MVVM" at all. You have an abstraction mismatch. There isn't a servlet/ASP/whatever model tied closely to the language or deployment environment. Frameworks/developers implement MVC/MVVM/whatever in JS. You are not going to find enlightenment at the language level.

# ¿ Jul 16, 2014 20:49

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

IM FROM THE FUTURE posted:

A MEAN stack isnt just any ole MVC stack. A Node.js backend is not like normal synchronous programming.

Neither is front-end JS, though. If you can't handle event-based/callback-as-lame-continuation flow control fluently, you're sort of hosed on modern FE work.

(Excepting generator models I guess, where you can write straight-line stuff that spans multiple event loop turns.)

# ¿ Jul 17, 2014 03:37

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

1000 book titles is going to be like 30K of data before compression, and it can be loaded in parallel with the rest of the page to not block long. You could keep it prepared and compressed so it's a static load and basically zero server impact.

Are multiple searches common per-load? If so you could do the first search on the server and hand back the results plus the full list for subsequent searches. You'd minimize latency, and let follow-up searches be client-side fast. Have to keep server and client search code in sync, though.

I generally make the decision by measuring. If the first thing I try is fast enough, on to the next thing.

# ¿ Jul 20, 2014 16:58

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

HTTP caching semantics should give you what you want if you set the control headers correctly and take advantage of If-Modified-Since request headers.

# ¿ Jul 21, 2014 11:26

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Knyteguy posted:

May want to try the newbie/get a job megathread.

A lot of that stuff seems irrelevant to me to get a job as a developer. If I going to be interviewing developer candidates, I wouldn't really care that you worked as a convenience store clerk. I wouldn't really care about much of the rest of it either besides the "Web Developer and Designer, Freelance, Newcity, NY Jan �14 to Present".

Consider adding a link to your github. If you don't have one then start one and get some small projects up on there. I remember another posted mentioned making a quick pastebin clone or something (maybe without syntax highlighting). I don't think it is necessarily a requirement, but I bet seeing some of your actual code would help get you to the interview stage.

Lose the clerk, but keep the other parts. Explaining technical stuff to non-technical people, jamming together tools to get the job done, teaching people -- those are all valuable skills and experience to show off.

github for sure, though.

# ¿ Aug 20, 2014 17:03

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

fuf posted:

I'd looked at React in the past and just had a look at react-router.

The thing I'm not sure about is React components only ever seem to have really small html snippets defined right there in the app code, like this:
code:
var Header = React.createClass({
  render: function() {
    return (
      <header>
        <ul>
          <li><a href="/">Dashboard</a></li>
          <li><a href="/inbox">Inbox</a></li>
          <li><a href="/calendar">Calendar</a></li>
        </ul>
        Logged in as Joe
      </header>
    );
  }
});
But I can't really do this for a full page's worth of content with paragraphs and images etc. Is there a method which uses external html files like with Angular's TemplateUrl?

I don't know of an existing component that wraps XHR and dangerouslySetInnerHTML (other than <iframe> :v:

), but DIY wouldn't be too hard. Keep the currently-loaded content in state, trigger a load of it on nav, and in render jam it in. The tutorial does this with the markdown comments, IIRC.

# ¿ Sep 9, 2014 20:05

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

L20N isn't very widely deployed, AFAIK, but it's used to localize FirefoxOS's UI, so it should be pretty robust. Staś and the team will likely be pretty supportive through mailing list or IRC if you need help.

# ¿ Sep 25, 2014 01:23

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 16:12

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Thermopyle posted:

the extra mental capacity taken up by having more logic to keep in your brain when reasoning about your code.

"Brainprint" is one of the most underestimated costs of optimization. Even where it's not much more code, it's usually harder to reason about.

# ¿ Dec 19, 2014 00:23

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