Client side talk (opinionated)


#1

React is a good library. The component paradigm for building complex interfaces is nice. Tried React for a while and it gets things organized…
But it’s not the only tech that offers that feature and something did not feel right.
There were many good discussions about the pros and cons, so I will skip that.

Angular 2… well I tried It, liked some if it parts, other parts not so much.
It needs a lot of configuration and framework specific explicitness. Developer writing a production app rarely appriciates all the extra typing.
It can have that React feeling if it is up to preference, thanks to ES2015 template strings
And the main issue, what is the status of the project? As far as I know, nobody knows.

The main thing that does not get mentioned is, what does React do for the the developers in the long run and what does it do for the evolution of the native web?

Here is a excellent point in that regard by Rob Eisenberg:

"Clearly I am biased, but let’s think about this. (creator of the Aurelia framework)
For years we have been saying that it’s a bad practice to put JavaScript code in your HTML. But Facebook comes along and tells you that you must put HTML in your JavaScript code and we just accept that as ok? Clearly this breaks separation of concerns, makes it harder to work with a designer, destroys the declarative nature of HTML and forces you to work with a non-standard language: JSX.

The big problem with React is that it encourages developers to abandon web standards. First off, you aren’t using JavaScript, you are using JSX. Second, instead of learning the real DOM APIs you are working with their virtual DOM, which is different. You can even see that events and properties are named different sometimes. Next, you are asking developers not to invest in upcoming standards like Web Components, which actually solve the problems that React is trying to solve. Also, don’t use CSS, use a non-standard JavaScript API…never-mind that there are browser standards being worked on (such as ShadowDOM and Scope Styles) that allow you to do the same things, but without the non-standard library.

In recent years the community has developed a solid way to address browser issues. You work based on web standards. When the standard isn’t implemented, you use a polyfill. Any library or framework for developing apps should be built on top of that approach. We should not adopt libraries or frameworks that advocate, either explicitly or implicitly, circumventing web standards or throwing them out entirely. We should endeavor to progress the native web.

As web developers, we need to think very carefully about the consequences of adopting various libraries or frameworks. We should adopt those which are based on standards and committed to them.

Recently, I’ve had conversations with developers who work on IE and Firefox. Both seemed to indicate that React was actually thwarting them as browser developers by taking developer focus off of the standards-based solutions which were in development. They indicated that the delay in bringing Web Components to the browser was actually linked to React’s disengaging web developers from the standards and focusing them on React’s components instead. That’s bad for all of us."

There are more point’s on the comment’s section https://channel9.msdn.com/Shows/codechat/036?WT.mc_id=dlvr_twitter_ch9

As a relative newcomer to Meteor community, I came to it because of the accessibility Meteor offers and elegantly designed reactive fullstack platform.

And as a relative newcomer, I do not see comfort in the client side of React or Angular 2. Opinion comes from a standpoint of someone who is not already business wise invested in the previously mentioned tech, and there are many, many other newcomers to Meteor with similar dilemma. I honestly believe there is a better option for someone who is starting “today”, with a brighter future.
A tech that has the accessibility in the spirit of Meteor, but the possibility to use the same superior client side that:

  • is from the inception architected with ES2015/ES2016
  • strives for clean code
  • strives for developer experience
  • does minimally intrude,
  • it is available today,

and to also apply it for scenarios where Meteor cannot be used, as it gets demanded from the clients and the constraints of the existing infrastructure they have. Lastly, as a “side effect” of it’s usage, elevating and evolving our industrys best practices and standards.

What is your opinion?


#2

I’m sorry but Web Components is a complete disaster. The idea is great for building reusable components. Not so much for a complete application. BTW browsers are a lot to blame, they are VERY slow at implementing it and the Shadow DOM is impossible to polyfill. You can blame React or Angular as much as you want, they are by far the best solution in the market if you want to get things done. Developers care about their users, not the Web standards and if they don’t serve them well, they couldn’t care less.

About your separation of concern with JSX, I think you’re wrong. HTML/JS/CSS are not concern, they are technologies. Would you rather split your neightborhood by house or would you prefer to have all the roof together, all the walls together, all the toilets together (that would be hilarious). I prefer JSX but hey, Angular is still there if you don’t.


#3

I’m sorry but Web Components is a complete disaster

Never said Web components were sunshine and rainbows, but it is on a track. Btw, Polymer recently had some interesting anouncements.

The idea is great for building reusable components. Not so much for a complete application

Isn’t React in its core great for building reusable components, a V in MVC, but less for complete application? Yes, the community has done a great job to enable React for creating complete applications, but in it’s core it was not designed for a complete app. For example the router. Do correct me if I’am wrong.

BTW browsers are a lot to blame, they are VERY slow at implementing it and the Shadow DOM is impossible to polyfill

Not sure for browser adoptation speeds, but lately things are moving faster.

You can blame React or Angular as much as you want, they are by far the best solution in the market if you want to get things done.

Not really blaming them, just stating I will not use them. But the blame is mostly on React, and by Angular I mean Angular 2. Best solutions today… don’t think so. Best solution when they were introduced… yes.
On the other side, really, at the end of the day, where is stated that Angular 2 is of critical importance for their business? That does not give me warm and fuzy feelings.

Developers care about their users, not the Web standards and if they don’t serve them well, they couldn’t care less.

Dear, fellow proffesional. In this day and age, do you really think it is a good idea to ignore web standards, digging a hole underneath our feet while doing a mantra, customer is always right? Is it not in our interest to to have good foundations, standards and tools built on it that will ultimatly serve in the interest of users and customers? User does not care how it is built, that is our responsibility.

About your separation of concern with JSX, I think you’re wrong. HTML/JS/CSS are not concern, they are technologies

Yes, they are technologies. And each technology (HTML, JS/CSS) should be given their fair due. The “concern” thing sounds to me as Facebook mantra . One should be “concerned” how he uses his technologies.

Would you rather split your neightborhood by house or would you prefer to have all the roof together, all the walls together, all the toilets together (that would be hilarious).

My whole point of this post is to try to see us all under one big roof, and under that roof,every one has their own needed space.

I prefer JSX but hey, Angular is still there if you don’t.

Angular gloriously served it’s purpose at the time it graced us with it’s awesomeness. But today, there are new heavyweights.

For me, Enter the Aurelia Framework. MIT licensed, backed by a company, as their main critical product. Using most of the ES2015/ES2016, component oriented, modular at it’s core, designed for great developer experience. When web standard matures it will be possibe to reuse it as a webcomponent, you can even use React in Aurelia with true two way databinding etc, etc. Code speaks for it self,so don’t take my word for it.


#4

Good practices are serving my users. They don’t need to be official Web standard to be good practices and if they come from Facebook, Google or Mozilla, I couldn’t care less.


#5

Yeah, if building my app in Adobe Flex or Silverlight served my users best, I’d sure as heck do that. Maybe the real answer is that web standards should come from things that people are already adopting and not from totally new ideas invented by browser designers. For example, document.querySelector is great because it just makes it easier to do what everyone is already doing with jQuery.

An example where the standards have not done as well is in something like IndexedDB. I don’t think that most people use this feature, and that’s one place where libraries like Lovefield et al are gaining a lot more ground because you don’t have to think about which feature set each browser supports.

Web standards have been good for some set of things, but there are a lot of places where they currently fall short. I wish browsers would spend more time implementing good runtime features like JS improvements and more control over CSS layout, and less time implementing end-user APIs.


#6

I think web pages and web apps are two quite distinctive things, although the border gets blurry sometimes.
AFAIK React with components is great for web apps where there is a lot of concern about state/actions on separate parts of the app.
Blaze (or smarty, or whatever templating system you use) is great for web pages, that have relatively few dynamic elements.

I’ve built quite a few of both in my life and I do see a great value in both aspects. It’s a question about what’s the focus of the development. I find it hard to blame Facebook for changing the “best practices”, when the “best practices” were meant to drive development of web pages, not web apps.


#7

Good for you mate! How about we all write a 500 word essay on why we aren’t using [insert here: language | framework | database | IDE | editor]

You’re probably making a stellar decision for yourself. Well done! Move on.


#8

@maxhodges
Good for you mate! How about we all write a 500 word essay on why we aren’t using [insert here: language | framework | database | IDE | editor]

Well, that would be offtopic in the context of Meteor stack, would you agree?

Are you trying to tell me that I cannot state my opinion in regard of Meteor client side library/framework?

React and Angular are the most popular client tech in the wild and receving the most attention, I think it is only natural it gets some… extra “love”.

Slightly offtopic, React is about/did surpass Meteor in the top 10 starred projects on github https://github.com/search?p=1&q=stars%3A>1&s=stars&type=Repositories (YAY)


#9

I don’t think you can judge the merits of embedding “HTML” in JS on the merits of embedding “JS” in HTML at all (“HTML” in JSX is not true HTML, it’s an XML approximation, and “JS” in Angular templates isn’t real JS either). I hate embedding “JS” in HTML because it can be annoying to deal with specifying the scope for where the JS variables come from in Angular or any other framework I can imagine using. I love embedding “HTML” is JSX because it’s simple to see what the scope of variables in the template are – they’re just determined by good old JS scope.

And the “JS” Angular has you embed in HTML is no more of a standard than JSX.

Rob has a fair point about making it harder to work with a designer. But for better or worse, almost every industry has slowly been demanding more technical proficiency in this day and age. Designers can always create mockups using simpler tools and work with a programmer to integrate their design into JSX.

JSX is JavaScript with a very simple DSL embedded in it. You’re not abandoning JS by using it.

React doesn’t prevent you from using Web Components. In fact, it’s easy to manipulate Web Components with React, and it’s even possible to turn a React Component into a Web Component.

You can totally use CSS with React. Some people advocate using only React’s inline styles instead of CSS, which seems to have turned into a myth that you can’t use CSS with React at all. In any case, to use React’s inline styles you have to know CSS – you use all the same properties, but simply in camel case instead of spinal case.

Polymer itself is not a standard. It comes with a polyfill for the web components standard, but the tool it gives you to design web components is just as proprietary as React, and actually it’s very Angular-like in putting “JS” in HTML templates and using two-way bindings.


#10

You are certainly free to do that, but every time I see someone open a “discussion” by announcing “Why I will not use/recommend xxx” It’s turns negative, and often nasty–generating smoke and heat but not much light.

If you’re unhappy with a technology maybe ask questions to find out how others are dealing with the issues. But your post isn’t a question as much as a series of contentious assertions. (“Your tools are bad and you are bad for using them.”) You’ve made up your mind. What’s left?

I don’t like watching sports, but if I post a 10 paragraph report on the reasons why sports are a waste of time, we can be sure a lot of people are going to think I’m being an asshole right?


#11

Ok, you are correct, I edited my post so it is a minimall series of contentious assertions. And I asked for an opinion.


#12

Meteor uses the same language on frontend and backend, mixing frontend and backend code not only in same folders, but even in same files. This way it does a bad thing for all web developers. Where’s the separation of concern here? Frontend devs will be forced to work on files which have backend code too, they will feel bad with that and they’re sure to break something on backend. What’s more, by using javascript on the backend, it stops people from learning such great languages as PHP, Python or Ruby. When another PHP framework gets abandoned, I’ll be sure to blame Meteor developers for that.

Meteor in it’s default config doesn’t use REST API for communication between frontend and backend, so when I decide to switch backend, I’ll have to write it from scratch. What’s more, Meteor slows down the progress of REST, because new Meteor devs won’t learn how to write proper API.

Now the worst. Meteor stops developers from writing native apps for phones. Instead of rewriting their apps in Java or Objective C, they use Cordova which is far from being standard in the mobile world. That’s clearly against the common interest of all mobile devs.

Somebody could say it’s not the only way to do things in Meteor. We can have clean separation of frontend/backend code, we can use REST API and all the other fireworks? But hey, we can separate JS and templates in React too. It’s possible. So why don’t people use it like that? Surely because they find the other way better.


#13

Oh man, this post really had me going for a while. Great work! https://en.wikipedia.org/wiki/Poe's_law


#14

Why does someone feel the need to state the technology he won’t be using? Why do other people want to convince him otherwise, when it does not have any impact for them? I should have studied psychology instead of CS.


#15

I would love React extension which will let you edit html in DOM and return to console exact line in JSX where you need to copy paste it :smiley:


#16

Well, It is not completely true that opinion of community does not have an impact on a person/persons.
Maybe my topic should have been Why will I use Aurelia

@manuel did a great job on his work on viewmodel package https://atmospherejs.com/manuel/viewmodel
and Aurelia is in similiar spirit with all in/out ES2015/ES2016, two way databinding without performance issues.
In one of his post he joked how Aurelia was going to be a thing of the “hour”.

Yeah, I’m starting to dislike my initial approach :smile:


#17

Not sure, but maybe React Developer tools is what you are looking for https://facebook.github.io/react/blog/2015/09/02/new-react-developer-tools.html