Aller au contenu

Onanisme informatique et Esotérie de nerds

RotUndWiss

Par RotUndWiss,
dans La Taverne

Messages recommandés

L'affreux

L'affreux

Posté
Posté

Très intéressant.

À première vue j'aime beaucoup React.

À part qu'il ajoute des attributs "data-reactid" sur tout ce qu'il crée et je ne vois franchement pas l'utilité, mais bon, chacun ses défauts.

Manifestement chez Facebook ils utilisent JSX que je ne connaissais pas. Ça leur fournit un système de template. Ce n'est pas utilisable avec TypeScript puisque les deux se compilent en JS. Je garderai TypeScript. Par exemple voici la méthode qui génère le code HTML dans leur troisième exemple sur le site de React (en JSX) :

  render: function() {
    return (
      <div>
        <h3>TODO</h3>
        <TodoList items={this.state.items} />
        <form onSubmit={this.handleSubmit}>
          <input onChange={this.onChange} value={this.state.text} />
          <button>{'Add #' + (this.state.items.length + 1)}</button>
        </form>
      </div>
    );
  }
Je l'ai réécrite en JS :

	render: function() {
		var h3 = React.DOM.h3({}, 'TODO');
		var list = TodoList({"items": this.state.items});
		var form = React.DOM.form(
			{"onSubmit": this.handleSubmit},
			React.DOM.input({"onChange": this.onChange, "value": this.state.text}),
			React.DOM.button({}, 'Add #' + (this.state.items.length + 1))
		);
		return React.DOM.div({}, h3, list, form);
	}
Écrire ainsi des éléments HTML sous la forme d'objets est pénible. Ça me fait penser aux objets des ORM qui charcutent le SQL.

Mais c'est une piste de réflexion.

Plus j'avance dans Angular et moins j'aime. Du coup il est bien possible que je retourne ma veste.

Merci.

Lien vers le commentaire
Rübezahl

Rübezahl

Posté
Posté (modifié)

Dans les pays développés, près de 30% des actifs sont aujourd'hui indépendants ou employés à temps partiel. Ces changements s'accompagnent de préoccupations légitimes quant à la sécurité de l'emploi et aux avantages sociaux qui lui sont liés. Mais dans leur dernier ouvrage, The Rise of the Naked Economy: How to Benefit from the Changing Workplace, Ryan Coonerty et Jeremy Neuner montrent que la nouvelle réalité présente aussi des avantages incontestables. Bien compris et maîtrisés, les changements à l'œuvre pourraient donner des existences plus productives, plus heureuses, plus pérennes.

 

Au revoir, Dilbert: l’émergence de l’économie nue http://www.paristechreview.com/2014/01/17/emergence-economie-nue

 

 

edit : Et si le CDI était une connerie ? - http://deboutlesgens.com/blog/et-si-le-cdi-etait-une-connerie/ …

Modifié par Vincent Andrès
Lien vers le commentaire
L'affreux

L'affreux

Posté
Posté

Je complète mon post précédent.

J'ai un doute sur React parce que j'ai toujours trouvé que Facebook n'était pas très fort justement en terme de programmation JavaScript. Leur interface continue à faire transiter du HTML et à charger ses vues comme des pages à l'ancienne. Leur système d'auto-rafraichissement des discussions communes (dans les groupes par exemple) marche une fois sur deux et encore…

Et côté performance Sencha leur avait mis la honte il y a un an suite à leur déclaration d'abandon de HTML 5. Sencha avait alors créé "Fastbook", une application JS pour démontrer que Facebook aurait pu mieux faire :

So the Fastbook app is the first to make use of a brand new “Sandbox Container” which programmatically detaches complex views and renders them into their own iframes, and thus partitioning the DOM tree. […]

For Fastbook, the News Feed, Timeline and Story views are individually sandboxed. Since all DOM elements are re-used to render data on-demand at high frequency, reflows are inevitable. The key is to make that process as cheap as possible. Sandboxing enables the News Feed to perform as if it is standalone, while actually is still a part of the much bigger DOM tree.

À ce propos j'aimerais bien me faire une idée de ce qu'ils appellent "sandbox". Le coup d'utiliser une iframe pour du sandboxing, c'est facile, je comprends. Mais ils ont l'air de dire qu'ils peuvent aussi isoler des sous-parties du DOM ce qui évite les reflow. Comment font-ils ?

Ou bien est-ce que ce n'est pas plutôt qu'ils utilisent un positionnement CSS qui évite ce reflow ? C'est comme ça que j'aurais l'idée de faire perso…

Lien vers le commentaire
Sloonz

Sloonz

Posté
Posté

À ce propos j'aimerais bien me faire une idée de ce qu'ils appellent "sandbox". Le coup d'utiliser une iframe pour du sandboxing, c'est facile, je comprends. Mais ils ont l'air de dire qu'ils peuvent aussi isoler des sous-parties du DOM ce qui évite les reflow. Comment font-ils ?

Une iframe en seamless ?

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe

Lien vers le commentaire
Poil à gratter

Poil à gratter

Posté
Posté

Intéressant retour. 

 

En fait je n'avais même pas regardé JSX tellement ça me semblait tomber un peu comme un cheveu sur la soupe par rapport à la philosophie du framework. Dans la présentation du gars d'Instagram il dit carrément qu'il trouve que les systèmes de template sont limités car ils ne sont de toutes façons qu'un sous-ensemble du DOM (et en bonus il faut apprendre un langage). Donc son point de vue est de directement utiliser JavaScript/DOM en lieu et place du templating, surtout que c'est plus optimisable et donc au final plus performant. Sans compter que JSX force à utiliser un préprocesseur et ne fonctionne donc pas avec TypeScript...

 

De mon côté, après avoir utilisé des frameworks Java côté serveur, je ne trouve pas si horrible que ça la syntaxe de React.DOM: par exemple j'ai utilisé Wicket et c'est encore plus lourd (et il faut compiler les classes Java). L'avantage que j'y vois c'est que ça produit du code navigable avec un IDE et refactorable. Bon maintenant faut que je trouve un peu de temps pour écrire un test "réaliste" pour me faire une idée plus précise sur le potentiel de React.js. Honnêtement j'ai pas non plus l'impression que ça soit le Graal, mais ils avancent quelques concepts qui me plaisent bien:

- des composants avec un état.

- composition plutôt qu'héritage

 

Après pour la comparaison Facebook natif/HTML 5 je ne sais pas trop quoi en penser, mais j'ai déjà vu des trucs similaires sur des technos que je connais mieux, et je me demande s'ils ne sont pas en train de comparer une version HTML5 que seul une poignée de développeurs peut pondre avec une version native qu'un développeur moyen++ peut pondre.

Lien vers le commentaire
L'affreux

L'affreux

Posté
Posté

En fait je n'avais même pas regardé JSX tellement ça me semblait tomber un peu comme un cheveu sur la soupe par rapport à la philosophie du framework.

En fait ils ont conçu JSX pour React :

 

React and JSX are independent technologies, but JSX was primarily built with React in mind. (source)

mais ils avancent quelques concepts qui me plaisent bien:

- des composants avec un état.

- composition plutôt qu'héritage

Moi aussi. Et l'idée générale de faire plus de calculs en JS pour alléger les traitements sur le DOM est intéressante.

Mais :

- Les composants n'utilisent pas le prototype (bonjour la signature en RAM) ;

- Les composants ne sont pas emboitables en pratique. Ceux que l'on emboite sont "stateless" (ils ne le disent pas mais j'ai fini par le comprendre). On ne peut donc pas prendre n'importe quel composant existant pour construire un composant englobant.

 

Après pour la comparaison Facebook natif/HTML 5 je ne sais pas trop quoi en penser, mais j'ai déjà vu des trucs similaires sur des technos que je connais mieux, et je me demande s'ils ne sont pas en train de comparer une version HTML5 que seul une poignée de développeurs peut pondre avec une version native qu'un développeur moyen++ peut pondre.

Ah si tout à fait et donc chez Facebook ils ne sont pas très forts en JavaScript. D'où ma méfiance pour leur techno JS.

Toutefois React apporte un éclairage critique sur Angular :

1/ Le couplage fort entre le M et le V de Angular n'est pas une bonne idée. Ça a l'air pratique au début, mais au final ça ne colle pas à une bonne représentation. On a tendance à mettre dans le modèle des choses qui ne concernent que la vue et ne devraient pas en sortir (par exemple l'état "menu ouvert / menu fermé" d'un menu géré en JS).

2/ Le mécanisme des templates a un défaut conceptuel : il est limité, aussi, pour repousser les limites, l'équipe d'Angular continuera à ajouter des fonctionnalités à ce langage. Pour moi c'est un défaut car garder Angular à jour impliquera d'avoir un fichier angular.js qui grossira. Ils ne rendront pas leur mécanisme de templates optionnel car ce serait perdre le binding et tout l'intérêt du truc. Or je suis convaincu qu'un framework ne devrait pas passer son temps à grossir.

Lien vers le commentaire
neuneu2k

neuneu2k

Posté
Posté

Petit passage rapide parce que ce fil est dans mon groove actuel.

 

Le "Modele" de Angular n'est pas réellement un modèle métier de mon point de vue, c'est un "view model", si on restreint l'utilisation du $scope à des objets dédiés à la vue, ça fait tout de suite plus de sens.

 

Les "vrais" modeles sont dans des services, et c'est le controlleur qui passe les plats entre les services et le view model du $scope.

 

Et du coup, avoir des états "interactifs" tel le menu ouvert/fermé dans le scope n'est pas un souci majeur, c'est sensé etre encapsulé dans un composent de menu, et -pour ce composent- ce boolean fait bien partie du view model (et une fois qu'on l'a écrit, on l'oublie ASAP !)

 

Utiliser le $scope pour le modèle métier, ça permet de faire des beaux tutorials et un TodoMVC court, mais pour des applis serieuses, ça me semble etre une erreur classique (ça me rapelle les horreurs que j'ai pu voir en delphi ou en VB...)

 

Angular, c'est l'outil frontend, de mon point de vue, c'est un client léger pur, sans état métier, et la séparation client/serveur traditionnelle doit rester présente, meme si le "serveur" est aussi en javascript et qu'il est aussi executé dans le browser !

 

Je retourne à mes activités normales...

 

Lien vers le commentaire
  • 2 weeks later...
Hayek's plosive

Hayek's plosive

Posté
Posté

L'exode des francais:

 

http://www.thelocal.fr/20140130/why-and-where-french-graduates-set-sights-abroad

 

How long?

Almost half of these graduates (44 percent) imagine themselves staying there between one and five years, and 11 percent said they would stay less than a year.

Meanwhile, 12 percent said they would stay between six and ten years and five percent said they would remain between 11 and 15 years.

Worryingly for France, 28 percent said it would be a one-way ticket, at least for the duration of their career, according to the survey.

Why?

So what has spurred this desire to up sticks and quit their homeland?

Sixty-three percent blamed the flagging job market, saying it spurred them to look abroad for work, while 51 percent blamed the state of the economy in general.

Over half (54 percent) attributed their desire to go abroad to the political and social environment in France

For 33 percent, it was the disappointing career prospects in France that propelled them to the exits. 

Perhaps surprisingly, over a quarter (26 percent) said they would quit France because of the low quality of life.

 

Lien vers le commentaire
Brock

Brock

Posté
Posté

Google images est un outil super rigolo

 

"le travail au Canada"

https://www.google.ca/search?q=le+travail+au+canada&safe=active&source=lnms&tbm=isch&sa=X&ei=YFbyUtzzCJbUsASVkIDQCw&sqi=2&ved=0CAcQ_AUoAQ&biw=1406&bih=681&dpr=0.9

 

"le Travail en fRance"

https://www.google.ca/search?q=le+travail+au+canada&safe=active&source=lnms&tbm=isch&sa=X&ei=YFbyUtzzCJbUsASVkIDQCw&sqi=2&ved=0CAcQ_AUoAQ&biw=1406&bih=681&dpr=0.9#q=le+travail+en+France&safe=active&tbm=isch

 

"work in the USA"

https://www.google.ca/search?q=le+travail+au+canada&safe=active&source=lnms&tbm=isch&sa=X&ei=YFbyUtzzCJbUsASVkIDQCw&sqi=2&ved=0CAcQ_AUoAQ&biw=1406&bih=681&dpr=0.9#q=work+in+the+USA&safe=active&tbm=isch

Lien vers le commentaire
Johnnieboy

Johnnieboy

Posté
Posté

Très intéressant. Il y aurait tellement de choses à dire.

Lien vers le commentaire
  • 1 month later...
Poil à gratter

Poil à gratter

Posté
Posté

Ouais j'ai vu ça, ils vont aussi ne supporter que les browsers qui se mettent à jour automatiquement (donc IE 11+), et passer en mode "mobile first". Vraiment de moins en moins convaincu par le framework. De toutes façons j'ai changé de projet et ne travaille donc plus avec Angular, ce qui me convient très bien finalement :)

Lien vers le commentaire
neuneu2k

neuneu2k

Posté
Posté

Le support des everyoung est à mon avis une bonne stratégie, une perte de business initiale mais en échange, la possibilité d'etre ultra-compétitifs face à des concurrents qui vont soit prendre le plus petit dénominateur commun, soit etre obligés de développer les features en double/triple pour avoir une application utilisable sur tous les browsers...

De plus en plus convaincu pour ma part, très opinionated, je ne m'en servirait pas pour n'importe quoi et il y des tas de situations ou jquery suffit amplement pour faire des trucs simples, mais pour faire des grosses applis avec des dizaines, voir des centaines de vues, je ne vois rien qui s'en approche.

C'est un framework clairement pensé pour faire des applications web monstrueuses, pas des "applets" web.

Lien vers le commentaire
Poil à gratter

Poil à gratter

Posté
Posté

Le support des everyoung est à mon avis une bonne stratégie, une perte de business initiale mais en échange, la possibilité d'etre ultra-compétitifs face à des concurrents qui vont soit prendre le plus petit dénominateur commun, soit etre obligés de développer les features en double/triple pour avoir une application utilisable sur tous les browsers...

De plus en plus convaincu pour ma part, très opinionated, je ne m'en servirait pas pour n'importe quoi et il y des tas de situations ou jquery suffit amplement pour faire des trucs simples, mais pour faire des grosses applis avec des dizaines, voir des centaines de vues, je ne vois rien qui s'en approche.

C'est un framework clairement pensé pour faire des applications web monstrueuses, pas des "applets" web.

Justement je ne suis pas persuadé que ça grossisse très bien, une application Angular. Je verrais bien comment notre expérimentation avec Angular se poursuit (c'est une moyenne appli).

À la limite j'ai été plus convaincu par cette présentation, en termes de "scalabilité" horizontale.

 

http://www.infoq.com/presentations/emberjs-url

 

M'enfin tant qu'on n'a pas fait, c'est toujours dur de prédire...

 

THIS. IS. LIBORG !!!

Voilà ! ;)

Lien vers le commentaire
L'affreux

L'affreux

Posté
Posté

C'est un framework clairement pensé pour faire des applications web monstrueuses, pas des "applets" web.

J'ai eu l'impression du contraire. C'est pratique pour des "applets" et par exemple sur leur page de présentation il y en a plusieurs qui coexistent. Ensuite si des applis monstrueuses sont peut-être jouables, le dirty checking élimine à mon avis l'option des vues monstrueuses.

Lien vers le commentaire
neuneu2k

neuneu2k

Posté
Posté

Les vues monstrueuses, en effet, ou plutot ça se fait, mais en court-circuitant le dirty checking sur les items et en ne le gardant que sur un proxy pour la "vraie" collection.

 

Mais dirty checking ou non, de toute façon, les vues monstrueuses, ça ne peut pas etre fait autrement qu'en faisant de la pagination smart avec la coopération du serveur, et il n'y a pas de solution générale à ce probleme (quand on prends en compte les filtres, le tri, la sauvegarde des modifications en cours...)

 

C'est aussi naze de prendre un template angular pour faire une datagrid monstrueuse que de prendre le composent natif de l'OS (hint, c'est PAS une bonne idée, JP Morgan l'a démontré depuis bientot 10 ans, un arbre de noel, ça implique un composent custom ou le rendu est totalement maitrisé par le code applicatif).

Lien vers le commentaire
Raffarin2012

Raffarin2012

Posté
Posté

 

C'est aussi naze de prendre un template angular pour faire une datagrid monstrueuse que de prendre le composent natif de l'OS (hint, c'est PAS une bonne idée, JP Morgan l'a démontré depuis bientot 10 ans, un arbre de noel, ça implique un composent custom ou le rendu est totalement maitrisé par le code applicatif).

 

Certes, mais quand on sait qu'avec un simple deflotching des multistrates/abrisseaux on gratte du reverse-estragon, on est en droit de se poser des questions...

 

Lien vers le commentaire
Sloonz

Sloonz

Posté
Posté

C'est aussi naze de prendre un template angular pour faire une datagrid monstrueuse que de prendre le composent natif de l'OS (hint, c'est PAS une bonne idée, JP Morgan l'a démontré depuis bientot 10 ans, un arbre de noel, ça implique un composent custom ou le rendu est totalement maitrisé par le code applicatif).

Je ne vois pas ce que tu reproches à l’API iOS pour les tables avec énormément de lignes.

Lien vers le commentaire
  • 11 months later...

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
Aller sur la liste des sujets
×
×
  • Créer...