Je ne vais pas reproduire les manquements déjà relevé dans le journal, si j'ai bien compris l'idée derrière tes librairies et tes interfaces l'idée c'est de développer des applications Web sans écrire de javascript ?
En gros le framework se charge d'écrire le javascript nécessaire a binder le serveur ("l'application") et le navigateur et tout ce gère coté serveur ?
Du coup au final l'application est en interface directe sur le web ? c'est donc un serveur web indépendant à chaque fois ?
Personnellement en tant qu'admin-sys ce genre d'appli je n'ai pas confiance, ça implique un vecteur d'entrée sur mes systèmes qui n'a jamais été vraiment testé en terme de sécu...
Pour packager une appli avec medias ça implique d'avoir un serveur web a coté juste pour les medias ?
Dans tout les cas mon plus gros warning sur ta techno qui me fait dire qu'elle ne peut pas prendre de l'élan est tout simplement que ça va à l'encontre des besoins "primaires" des utilisateurs: de la réactivité.
Les applis web actuelles cherchent toutes à optimiser les opérations faites 'en local' (sur le navigateur client) et à réduire les interactions coté serveur (réductions des échanges en nombres de requêtes, mise en caches des datas, stockages locaux au navigateurs, opérations asynchrones, ...) car au final c'est ça qui coute le plus.
Et au contraire d'un javascript généré dont on a pas le contrôle on va préférer un JS optimisé, "compilé" pour être testé et validé sur les différents navigateurs, voir traduit depuis un language superset un peu plus clean type typescript.
Tes librairies traduisent d'un mode de fonctionnement client-serveur fort datant des débuts du web et qui sont à l'abandon maintenant
# concept "daté"
Posté par -=[ silmaril ]=- (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 10.
Je ne vais pas reproduire les manquements déjà relevé dans le journal, si j'ai bien compris l'idée derrière tes librairies et tes interfaces l'idée c'est de développer des applications Web sans écrire de javascript ?
En gros le framework se charge d'écrire le javascript nécessaire a binder le serveur ("l'application") et le navigateur et tout ce gère coté serveur ?
Du coup au final l'application est en interface directe sur le web ? c'est donc un serveur web indépendant à chaque fois ?
Personnellement en tant qu'admin-sys ce genre d'appli je n'ai pas confiance, ça implique un vecteur d'entrée sur mes systèmes qui n'a jamais été vraiment testé en terme de sécu...
Pour packager une appli avec medias ça implique d'avoir un serveur web a coté juste pour les medias ?
Dans tout les cas mon plus gros warning sur ta techno qui me fait dire qu'elle ne peut pas prendre de l'élan est tout simplement que ça va à l'encontre des besoins "primaires" des utilisateurs: de la réactivité.
Les applis web actuelles cherchent toutes à optimiser les opérations faites 'en local' (sur le navigateur client) et à réduire les interactions coté serveur (réductions des échanges en nombres de requêtes, mise en caches des datas, stockages locaux au navigateurs, opérations asynchrones, ...) car au final c'est ça qui coute le plus.
Et au contraire d'un javascript généré dont on a pas le contrôle on va préférer un JS optimisé, "compilé" pour être testé et validé sur les différents navigateurs, voir traduit depuis un language superset un peu plus clean type typescript.
Tes librairies traduisent d'un mode de fonctionnement client-serveur fort datant des débuts du web et qui sont à l'abandon maintenant