plexicle

I have tried to get in to React all week. The technology is easy, but it's Webpack that I'm having trouble enjoying.

All I want is are two simple configs. A dev one with a server/hot loader, and a prod one that concats/minifies. ES2015. That's it. That just doesn't exist out there. It's either no decent production bundler, or it's like 15 files and 900 lines of configuration that seem completely overkill.

I don't know. I don't have time to learn how the tooling works, but I also don't want a bunch of magic. Angular 2 is looking really good right now even with the (still very incomplete) angular-cli tool.

Dang. I just want my simple gulpfile back.

I love GCE. I really would like to see Node on it natively, without the need for ManagedVM. I tried it a while ago and did not want to deal with all of the Docker stuff. It was especially a pain on Windows. :(

Oh, it actually worked? I waited a couple seconds and closed it, assuming it was broken.

Big proponent of JS myself.

I totally agree with you here.

That's a really big deal. I wanted to fix a bug or two and saw coffee last year and noped out. Glad to hear they are going back on that one.

Kind of curious why they made that decision in the first place.

Oh, they are a Ruby shop. Right.

I was debugging a Node app on Windows with VSCode about 20 minutes ago.

What? Not even close. That's a ridiculous statement.

They both use electron, but Microsoft is baaarely using it for some UI pieces. That's really the only similarity between them.

What the hell? How...

Great, looking forward to reading these. Thanks!

Hey Rob- that was probably unfairly harsh of me. I have tried to like the syntax for the last year and I've had trouble.

Anyway, I know you are a big contributer, do you mind showing me the discussion where we determined '*ngFor=' and '[(two-way)]=' was implemented to play nicely with WC? I would be interested in reading. Thanks!

Are you under the impression these things aren't possible (or even easier?) with web components or vanilla JS? You don't need a big framework for any of that.

Re: state control. The "mediator pattern" is a cool way to write some apps and it addresses a lot of these concerns (with a parent app-element). It's not Polymer specific, but here's a cool video going into a little more detail: https://www.youtube.com/watch?v=ZDjiUmx51y8

I should say, my post was more about web components and less about Polymer. Polymer is just one way to do it right now, and you're right, it is opinionated.

You don't need a library at all if that's what you prefer.

The polyfills are there now and they are solid. Webcomponents.js is small and effective. The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper elements. That's not what I'm talking about here.

That's exactly the wrong question.

The right question is: "are there any substantial apps that take advantage of native Web Components (polyfill or not)?" The answer to that is: "yes, a lot."

Polymer is just one way to write the components. X-Tag is another. Pure JavaScript is another. Use one of them or use them all. No big overarching framework required.

To me it really feels like Polymer is taking all of the pros from both of these "libraries" or "frameworks" or whatever you want to call it and none of the cons. Why aren't we talking more about that? Polymer is a fraction of the size. It's one of several ways right now to write custom components. React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For what?

Sorry, no. My 2016 isn't going to come down to me deciding between React's perverted DSL and crazy toolchain or Angular2's massive cluster$&!% of a bundle with cringe-inducing template syntax. No thanks.

I have followed this long enough. To a lot of people, adding Flux, Webpack, TypeScript, whatever, might seem like the beginning of the future of front-end development, but I see something different. I see 2016 as the year that people slowly begin to realize that while components ARE the future, you don't need big frameworks or libraries or 4000 node modules. This is the year of pure, well-written, and fast web apps. This is the year of framework fatigue.

Sadly, you're not wrong. So I'm stuck trying to find the evils that I'm most content with being forced to put up with.

Absolutely. In the process of doing so. It's more about the fact that they WOULD do it, not so much that I can "opt-out". It's bad enough that it's even happening-- it's 10x worse to me that it's "opt-out" and that they are flat out lying about it to people.

I've actually just left T-Mobile BECAUSE of the shady stuff they are doing with Binge-On. The "all of our customers LOVE Binge-On!" is absolutely not true. Looking at you John.

I don't understand the point of this comment. Almost every new Google service I see is written in Angular. Why are we jumping on comparing it to React already?

Maybe let's withhold judgement until we actually use it. Just a thought.

Well that's great news. It wasn't always that way. I'm glad to hear it is.

It absolutely could have changed since I've used it. I'm hearing you might not need an "account" any more but you still need the app and/or some kind of quick verification? Probably worth checking out again.

In either case, I like that with Wallet you don't even need an app.

It uses a reverse ACH trick. It's like charging the debit card, but in reverse. It's also why it's nearly instantaneous.

Square's Cash app does the same thing.

If you found a way to have the address bar show an HTTPS lock on a Google domain despite actually being on one, then you've found a big hole and you could make a lot of money by reproducing/reporting this security flaw.

The fact that you have found "several ways" is intriguing. You are either mistaken, or you're one of the greatest security researchers out there.

No? Unless it's completely changed since I used it last. You could send an SMS but it was a link to create an account (or $CashTag or whatever they call it) with the app. Then you put in your debit card. Then you can accept the cash.

You don't need an account of any kind if you are the receiver here. You just put in a debit card and you get the money.

So it's easier for the receiver but still requires a Wallet account for the sender.

All that's left is to do this exact same thing but in reverse. Let a GW user send a secure REQUEST link that only requires card information to pay.

I forced myself to use it all day yesterday and today so far (most of the time, I was writing Go).

I am loving it, honestly. Microsoft has a great product here.

This is spot on for me as well. I always wondered how VSC was so much faster given that they are both on top of Electron. In either case, this is all great news.

Just speed. Still can't keep up with the other major players.

I like that it's open source, but I couldn't bring myself to contribute because it's all Coffee. That's more of a personal gripe, though.

I'm not an expert in Go, but can't you inline a statement before the conditional?

  value, err := bar(); err {
    // there was an error
  }

I like how that looks, personally. Obviously YMMV.