Live data from Hacker News

Node.js and the new web front-end

nczonline.net

101–110 of 163 posts

Re: Node.js and the new web front-end

#101
post #56

> 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…

If you use jshint (it will yell at you when using == with non-null) much (all?) of these problems go away.

Re: Node.js and the new web front-end

#102

> 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…

I can understand some trepidation around actual checkout but seriously, how much linguistic fortitude do you need to implement a shopping cart?

Exactly this, I'd be far more concerned about which datastore was used for a shopping cart than which programming language.

Re: Node.js and the new web front-end

#104

Earlier quoted context omitted.

That's basically it, except in most shops, the controller is this middle ground. It's on the back end, but the back end engineers can't really do the job on their own, so the front end developers end up writing the controllers, calling out to services that are written by the people who are actively implementing the business logic. In most cases, there are really four layers rather than three, and the two groups handl…

That's part of what I was wondering about. In the classic MVC sense, we're turned the Controller into a distributed system with a footprint both on client and server.

It's closer to a MCVMV or model, controller, view-model, view. Which is close to a MVVM pattern but adds a controller in. In my view the model is back-end, controller is mostly backend (processes the api requests and return the model data or the correct data value to the client), View-Model (grabs data via the model api and loads it into a model class on the client, this model class may or may not be the same structure as the server model, usually mapped to an/multiple api end point(s)), and View is the actual client side presentation.

That's how I tend to think of the pattern, it's not really MVC anymore it's a new pattern that is evolving out of MVC.

Re: Node.js and the new web front-end

#105
post #61
post #56

Earlier quoted context omitted.

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…

I think Typescript solves a lot of these problems. The type system is amazing, conversions are explicit. Syntax is slightly improved, built-in class system. The others I don't really mind: I like writing event-loop code over threads, and have never once run into Object.prototype problems in the wild.

I've been using TypeScript for experimenting with Node.js and while it's a great solution there's a few difficulties some might face with it:

-TypeScript definitions for many libraries, such as express are out of date and require modding to use.

-Visual Studio has no built in support for TypeScript with Node for debugging, but it has been mentioned as likely to be added by the TypeScript team eventually.

-There are third party plugins for Node in Visual Studio for debugging, but none support TypeScript yet.

I've found the best solution thus far is Intellij IDEA or WebStorm, as it has support for both Node and TypeScript.

Re: Node.js and the new web front-end

#107
post #56

Earlier quoted context omitted.

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…

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.

Was just going to say, a large percentage of online shopping is based on open source e-commerce solutions, most of which are written in PHP. Which shares (and possibly overshadows) Javascript's problems.

Re: Node.js and the new web front-end

#108
post #76
post #61

Earlier quoted context omitted.

I think Typescript solves a lot of these problems. The type system is amazing, conversions are explicit. Syntax is slightly improved, built-in class system. The others I don't really mind: I like writing event-loop code over threads, and have never once run into Object.prototype problems in the wild.

What's so good about TypeScript's type system and what problem does it solve?

the two best features of Typescript's type system IMHO are:

- structural typing for interfaces (which means that classes implicitly implement an interface if the definitions match)

- gradual typing (mainly the ability to convert between 'any' and other types implicitly, which makes it much easier to interact with JS libraries/port JS code to Typescript.)

More generally speaking, Typescript aims to solve the problem of maintaining large codebases by giving you the additional security of static typing. The idea is that many simple errors can often be caught by a compiler, but would be much more time-consuming to find otherwise.

Re: Node.js and the new web front-end

#109
If you are smart enough you can make every code fit your need and reach the code quality you need.

JS weakly typed ? Seriously learn on how to adapt your coding style. I've built more than 20 API/Apps and Node is the best thing I ever had to build networked apps. I have a J2EE/Spring, Python and RoR background, NodeJS/NPM took the best of every stuff created before.

In my case, I need to be fast and JS + NodeJS + his awesome community permits me to build stable, innovative solutions and high performance networked app in a very short amount of time.

We are in a world of inter-connected apps. NodeJS is for that. Adapt yourself.

I need hacker modules to accomplish and solves problems of my current worlds, hacker offers me that.

NodeJS is great and lot of thing I read before was old school shit.

And BTW, yes a lot of logic must be delegated to the client side. This is a trend and it will not be stopped. Rendering page server side, qu'est ce que je peux pas entendre comme connerie parfois.

Re: Node.js and the new web front-end

#110
post #56

Earlier quoted context omitted.

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…

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)
Post reply on HN