Jump to content

JS 2.0 - opinioes


coxosclassic
 Share

Recommended Posts

Boas a todos,

Todos devem saber que ha ja uns anos se tem vindo a falar de uma suposta nova versao de JS (Javascript 2.0)

Nao consigo encontrar muito mais info sobre o assunto:

http://m.softpedia.com/javascript-2-0-a-quick-preview-118693.html

Alguem sabe se isto podera ir mesmo para a frente?

Tenho vindo a usar algumas linguagens para desenvolvimento de 'frontend', mas sempre que preciso usar javascript, fico com um 'no na garganta'.

Nao quero com isto dizer que acho js uma ma linguagem, nem muito menos tentar desvalorizar a sua importancia, apenas sinto que esta um pouco 'desatualizada' em relacao a outras, dai eu concordar com uma nova versao, mais aproximada a standards atuais.

O que acham desta possivel nova versao?

Concordam que seria positivo?

Se nao concordarem, quais os motivos?

Cumps,

cc

Edited by coxosclassic

Cumps,

cc

Link to comment
Share on other sites

A linguagem já tem evoluído, mas só consegues suporte se as pessoas actualizarem os browsers que usam.

http://en.wikipedia.org/wiki/ECMAScript#Implementations

EDIT: Já agora, porque é que achas que o Javascript está desactualizado?

Edited by KTachyon

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Link to comment
Share on other sites

Eu andei a tentar escolher bem a palavra "desatualizado"... 🙂

O meu problema com JS é que o seu "conceito de OOP e a sua semântica"... são muito estranhos. Faz-me lembrar (os bons) tempos de ActionScript1.0, dai o meu termo de "desatualizado".

Visto JS ser das linguagens mais importantes para frontend (praticamente tudo na web é JS) não consigo perceber o porquê de JS não ser "mais" OOP.

Podemos sempre usar o conceito, mas parece mais um hack na coisa do que propriamente codigo limpo (comparando com outras linguagens).

Heis algumas situações que sempre me fizeram/fazem muita confusão:

(un)Typed Variables:

var a;
a = "hello";
console.log(typeof(a)); //string
a = 1.0; //urgh... 
console.log(typeof(a)); //number (?!?!)

Super vantajoso em situações simples, mas não muito "saudável" no desenvolvimento de uma aplicação mais complexa.

Situações destas podem facilmente gerar bugs desnecessários e até tornar a app mais ineficiente. Um erro de compilação nestas situações ajudaria a antever possíveis problemas.

Class definition:

- Exemplo Javascript

//constructor
function MyClass() {

 //private method
 var myPrivateMethod = function() { }
}
MyClass.prototype {
 constructor: MyClass,
 //public method
 myPublicMethod: function() { }
}

- Exemplo Java

class MyClass {

 //constructor
 public Myclass() { }

 //public method
 public void myPublicMethod() { }

 //private method
 private void myPrivateMethod() { }
}

- Exemplo C#

class MyClass {

 //constructor
 public Myclass() { }

 //public method
 public void myPublicMethod() { }

 //private method
 private void myPrivateMethod() { }
}

- Exemplo ActionScript 3.0

public class MyClass {

 //constructor
 public function Myclass() { }

 //public method
 public function myPublicMethod():void { }

 //private method
 private function myPrivateMethod():void { }
}

A definição de classes (ou objeto) em JS é bastante diferente do normalmente usado, e nem posso falar de conceitos como implementação de interfaces, static functions ou protected functions pois eles ou não existem, ou são hacks.

Estas e mais situações, são o que me fazem crer que Javascript apesar de ser uma linguagem extremamente importante, parece que está "desatualizada" em termos de OOP e semântica (comparando com outras linguagens do género).

E o próprio standard ECMAScript no qual Javascript se baseia, permite o uso destes e muitos outros conceitos OOP.

Com o cada vez maior número de WebApps a requerer um frontend mais complexo, acho que uma nova versão da linguagem seria muito positivo para o desenvolvimento web atual.

São estes (+-) os meus pontos de vista como programador frontend.

Qual a vossa opinião a uma suposta nova versão da linguagem? Achariam positivo?

Cumps,

cc

Edited by coxosclassic

Cumps,

cc

Link to comment
Share on other sites

Eu não vejo grande problema em utilizar function em vez de class. Já estou até bastante habituado a fazê-lo quando trabalho em Javascript. Já desenvolvi alguns projectos que têm dezenas de milhares de linhas de código em Javascript e isso não foi um problema. O verdadeiro problema é mesmo as práticas que algumas pessoas usam quando desenvolvem em Javascript (ou a falta de práticas) que leva a um emaranhado de código que acaba por se tornar num campo minado.

Se o problema é só a semântica, para mim não faz diferença absolutamente nenhuma. Até porque vais poder continuar a fazê-lo com funções que são bastante mais flexíveis e poderosas (se as souberes usar) que o conceito de classes que encontras nas linguagens que indicaste A introdução do conceito de classe não é propriamente uma forma de dar poder ao developer, mas permitir reduzir a curva de aprendizagem.

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Link to comment
Share on other sites

Eu não vejo grande problema em utilizar function em vez de class. Já estou até bastante habituado a fazê-lo quando trabalho em Javascript. Já desenvolvi alguns projectos que têm dezenas de milhares de linhas de código em Javascript e isso não foi um problema. O verdadeiro problema é mesmo as práticas que algumas pessoas usam quando desenvolvem em Javascript (ou a falta de práticas) que leva a um emaranhado de código que acaba por se tornar num campo minado.

Isso é outra das minhas grandes preocupações (bad-practices, emaranhados de código, etc). Já perdi horas a resolver problemas com código JS de outros developers, e também já fiz perder muitas horas a outros developers....

Acho que isto é um problema pelo qual todos passamos.

O mesmo se passa com outras linguagens sem dúvida, mas nunca me é tão doloroso, pois passa sempre por OOP e acaba por ser mais pratico e rápido identificar problemas.

Se o problema é só a semântica, para mim não faz diferença absolutamente nenhuma. Até porque vais poder continuar a fazê-lo com funções que são bastante mais flexíveis e poderosas (se as souberes usar) que o conceito de classes que encontras nas linguagens que indicaste A introdução do conceito de classe não é propriamente uma forma de dar poder ao developer, mas permitir reduzir a curva de aprendizagem.

Exato, o reduzir a curva de aprendizagem é outro ponto que acho extremamente importante.

Sendo o conceito e semântica "OOP" um standard em desenvolvimento de aplicações (web, mobile, desktop, console), seria muito mais fácil e prático para novos developers começarem a perceber e a desenvolver. Existem cada vez mais pessoas a começar a desenvolver ou a querer aprender, sendo que a existência de "guidelines" só iria facilitar, e o conceito "OOP" serve perfeitamente essa "guideline" de uma forma mais abrangente.

Quanto á semântica, isso dá jeito por uma questão transversal. Por vezes é preciso de andar de um lado para o outro (NativeApp - WebApp) e pelo menos é mais fácil/rápido perceber o que estou a ler 🙂

Por outro lado, também concordo que o "Loose Typing" e "Functional Programming" caracteristicos de JS faz coisas fantásticas quando bem implementadas, mas isso é aquela questão da "faca de 2 gumes", pois por outro lado, "OOP" também permite coisas muito interessantes.

Já agora, alguém sabe mais acerca disto? (Javascript 2.0)

Apenas consigo encontrar info dos links deste post.

P.S - podiam fornecer links, livros ou até opiniões sobre boas práticas em programação JS?

cumps,

cc

Cumps,

cc

Link to comment
Share on other sites

Se estás à procura de informação sobre o ES6, tens este 'livro', onde podes ajudar o autor.

Edited by KTachyon
  • Vote 1

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Link to comment
Share on other sites

Eu não vejo grande problema em utilizar function em vez de class. Já estou até bastante habituado a fazê-lo quando trabalho em Javascript. Já desenvolvi alguns projectos que têm dezenas de milhares de linhas de código em Javascript e isso não foi um problema. O verdadeiro problema é mesmo as práticas que algumas pessoas usam quando desenvolvem em Javascript (ou a falta de práticas) que leva a um emaranhado de código que acaba por se tornar num campo minado.

[...] A introdução do conceito de classe não é propriamente uma forma de dar poder ao developer, mas permitir reduzir a curva de aprendizagem.

A flexibilidade de linguagens como o Javascript (e outras linguagens) é propiciarem a escrita de mau código. Adicionalmente, a flexibilidade associada a tentar adivinhar o que é que o programador queria fazer (fazendo conversões de tipos automáticas, e não obrigando à declaração de variáveis, por exemplo) também leva a que muitas vezes erros sejam escondidos pela linguagem (quando em linguagens mais rígidas o compilador detectava logo o erro).

Esta é muito boa para aumentar a produtividade na escrita inicial do código (faz-se muito com pouco código), mas parece-me má na parte da manutenção do mesmo (que a detectar erros, quer a modificar o código, principalmente quando foi escrito por outros). É claro que se formos disciplinados podemos minimizar este problema, mas sobra sempre o problema do código escrito por outros.

Link to comment
Share on other sites

Mas a escrita de mau código não é necessariamente culpa da flexibilidade da linguagem. É mais por falta de conhecimento da pessoa que está a desenvolver.

Acredito que a existência de conceitos mais parecidos com os de outras linguagens de programação possam eliminar muitos problemas que programadores menos experientes têm, mas não quer dizer que não se deva aprender a escrever bom código utilizando o método flexível.

De facto, muitas coisas que estão para ser implementadas no ES6 não são impossíveis de implementar hoje. Implicam é perceber mesmo o que se está a fazer.

Das piores coisas que tenho visto escritas em Javascript, há muitas que vão continuar a acontecer e que o ES6 não vai resolver. Um exemplo disto foi uma situação que me aconteceu há menos de um mês:

Tive que trabalhar com uma biblioteca que trazia uma dependência que era uma biblioteca de internacionalização que tinha um grafo de chamadas relativamente complexo. O autor teve problemas com a implementação assíncrona das chamadas XHR e resolveu fazer (martelar) chamadas síncronas para obter os dados que precisava. Isto fazia com que a thread do Javascript bloqueasse quando a biblioteca estava a obter os dados e, se a ligação tivesse alguma latência significava que não iria haver qualquer código Javascript durante todo o tempo que a biblioteca demorava a carregar os dados. Tive que fazer um fork ao repositório da biblioteca e refactorizar parte da implementação para poder passar a suportar todos os pedidos assincronamente.

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Link to comment
Share on other sites

pois, o problema de mau código esta sempre presente.

Deveria de existir documentação "oficial" sobre boas-praticas/guidelines de desenvolvimento JS. Tal como a Google ou a Apple têm.

Existe alguma entidade responsável pela manutenção da tecnologia? isto é, quem decide novas versões, best-practices, etc?

cumps,

cc

Cumps,

cc

Link to comment
Share on other sites

Não existe uma entidade que defina boas práticas, até porque podem existir várias abordagens diferentes. Cada equipa de desenvolvimento define as suas próprias práticas e têm a responsabilidade de as cumprir.

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.