111–120 of 163 posts
> I was never a fan of PHP Interesting how the same people who are "not fans" of PHP somehow like Javascript. As if it's better.
I'm a fan of both PHP AND Javascript! Take that, haters!
OK, dumb question time. How are front-end and back-end defined? To me the distinction was about the location of execution. "Front-end" meant "in a browser" and back-end meant "anywhere else with some surface addressable via HTTP". Now it seems that "front-end" means "View and Controller" and "back-end" means "Model", except ... not quite. Sometimes. On the other hand, perhaps I protest too much. It's not as though th…
We might need a change in terminology.
> As much as I love JavaScript, there are just some things I don’t want written in JavaScript – my shopping cart, for example. After developing almost exclusively in JavaScript for the better part of the past year (and doing a lot more in the previous 6), I'm convinced that this mentality is going to start fading as more and more developers become more capable and productive with JavaScript. There's nothing inherentl…
It doesn't have an adequate type system. There are too many silent conversions. The syntax is very clunky. All the object systems feel hacky and they can't be relied on to interoperate with each other. Problems like no standardized threading support or decimal type could be resolved in the future. But the language as it exists currently lets you override everything, and that's the sort of thing that you can't remove…
> As much as I love JavaScript, there are just some things I don’t want written in JavaScript – my shopping cart, for example. After developing almost exclusively in JavaScript for the better part of the past year (and doing a lot more in the previous 6), I'm convinced that this mentality is going to start fading as more and more developers become more capable and productive with JavaScript. There's nothing inherentl…
Devil advocating: I coded exclusively in javascript from 2006-2011. Most of that time was spent at Meebo, where we authored one of the most sophisticated JS application in existence at the time. It was great stuff! I've worked extensively with node.js 2011-mid2013, launching multiple backends written partially and exclusively in node. Lots of fun! On https://github.com/marcuswestin I maintain multiple widely used ope…
This is a disaster. Why would you want to create such a complicated system? node.js has a bright future and will be able to replace languages such as Python, Java, C#, etc. But why do two back-ends when you can do one instead?
If you're starting from scratch, you can choose a cleaner setup. But if you're dealing with an existing site, you have to figure out if and how you can migrate all the existing functionality. For any non-trivial case (or one with a realistic budget), you're not going to be able to just do a re-implementation and single cutover.
Earlier quoted context omitted.
Almost every shopping cart in existence right now is written in PHP, Python or Ruby, and they have much of the same "issues". Write tests, use a good bignum library, maintain code standards. Syntax is subjective, I find it pretty nice when following a certain style. Almost nobody modifies Object.prototype, and we now have plenty of APIs to deal with that - defineProperty, seal, freeze, etc.
What's the big deal with getting bignum into js? Everything else I can agree with, but not having 64bit int support in a server side language has to hurt. (just look at most node db adapters and bigints are handled as strings)
This new javascript wave in which we eschew the needs of the consumer is going to start costing companies big. Processing power, memory, and power consumption are still a pretty big deal in the mobile sector and offloading all these responsibilities to build the view client-side are a huge mistake. Engineers that make their lives easier at the expense of the customer will find themselves in a very empty and very opti…
It would be interesting to try a solution where Node.js incorporates itself either on the client side or the server side depending on the device. Or even putting Node on both sides and "load balancing" depending on processing power. I'm also really interested in seeing how feasible it would be to push all Javascript to the server and basically letting the client act as a dummy terminal that sends and receives Javascr…
Earlier quoted context omitted.
Are you claiming to have an objective yardstick for comparing the goodness of languages? (Don't answer that.) If not, please remember that different languages are just that -- different, not necessarily better or worse. Personal attitudes towards the differences between languages are totally normal. Bearing this in mind will help the conversation proceed in a more civil manner.
> "not necessarily better or worse" I don't agree with that. Sure, comparing something from completely different domains (for example, SQL and HTML) doesn't make sense. However, for some languages (e.g. C#/Java, Python/Ruby, etc.) it is entirely possible to compare them and point out which is better in some aspects or worse in others. What I'm saying is that Javascript and PHP are comparable (now that node.js exists…
JavaScript even with the bad parts is still more consistent and friendly to use than the core methods within PHP, inconsistent naming structures, parameter ordering and a lot of other issues at the language level.
I've NEVER liked PHP as a language... and that stems from VERY early on in web development. I've used a number of platforms and languages over the years, and none have irked me nearly as much as PHP has.
Earlier quoted context omitted.
Not impossible, but not easy either considering PHP is single-threaded and synchronous.
I've never heard of languages being synchronous or asynchronous before. It looks like PHP ships with asynchronous DB APIs.