.NET/JS developers in Melbourne

[Adam Schröder]

Hi All,

We are looking for a couple of enthusiastic and experienced .NET and JS developers to join a small team of 5 to re-envisage our product with latest technologies and needs. 

Required technical skills:

ASP.NET MVC

HTML/Razor

Javascript/jQuery

Css/Less

SQL (PostgreSQL)

We have the ability to move quickly and are not limited by MS technologies.

If you would like to here more, drop me an email at asch...@inlogik.com

Thanks,

Adam

Head of Development

Inlogik 

[Andrew Clancy]

As this is a discussion list I feel compelled to offer some friendly discussion :) feel free to disregard as I don't know your full project spec of course.

If your product is an app rather than a site I highly recommend the typescript/angularjs/rest webapi stack. There's not much need to generate html on the server these days, unless you have seo (or, god forbid ie6) concerns, and massive performance, ux & productivity benefits to doing it all clientside.

Of course you can always mix the mvc and web api approaches for your search-engine facing pages. Throw in some signalR to keep the client up to date and bootstrap etc for look & feel/ux.

--
--
You received this message because you are subscribed to the "ozaltdotnet" group.
To post: send an email to ozalt...@googlegroups.com
To unsubscribe: send an email to ozaltdotnet...@googlegroups.com
For more options, visit this group at
http://groups.google.com.au/group/ozaltdotnet?hl=en-GB
 
Find us on the web at http://ozalt.net
---
You received this message because you are subscribed to the Google Groups "ozaltdotnet" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozaltdotnet...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Andrew Clancy]

Note you can still cache on the server in web api, including per session, you're just going to be caching pure data.

[Michael Ridland]

Just to fuel the fire..... 

"massive performance" is debatable because twitter has gone back to server side rendering to improve their 'Time to First Tweet'.

"productivity" - this is debatable also, I find the tooling for this type of development is lacking, so it actually makes it a slower development time.

[Andrew Clancy]

I'd argue that as twitter is very light on content per page and can federate a lot of their workload, it's a very different scenario to say a SPA with lots of data going over the wire continuously for a single screen. There's loads of great tooling out there once you break the vs shackles, webstorm's my preference.

[Colin Scott]

I'm not a front end dev (or I would totally apply :) ) but your performance is going to vary significantly depending on all kinds of factors such as the complexity of rendering logic, the size of the resultant HTML, cachability, efficiency of the target JS interpreters etc. Considering options where you can easily mix and match serving JSON/XML/HTML representations as well as leveraging HTTP as much as possible would seem the better core approach. Then you can spike different options and get some real numbers relevant to your particular scenario. I've been playing with Nancy recently which can do some nifty content negotiation things, that kind of approach may be useful.

Yours in Awesome

Colin Scott

http://www.abstractcode.com/

[Adam Schröder]

We make heavy use of HTML conventions, which tie into HTML generation, URL generation, validation etc, which at the moment is working great for us. I'm still not quite/have yet to be convinced by all client side work with angular etc. I'm not that sure it provides many benefits in the current app. 

However saying that, we are also developing a mobile application using PhoneGap and Angular, which I think does suit heavy client side work. 

[Andrew Stone]

It's early days, but right now we are going through the process of building out a new stack and ALM tooling for JavaScript browser MVCs apps and an API server implementation (JSON). 

The plan is to use this new stack going forwards instead of .net and rails stacks we have been using to date... been testing angular and ember still pretty undecided on the server implementation ATM...

The kicker being that you can use the API server for thick client mobile apps and as well as web apps... so there is a simplification to be had there. 

So, I will have some real skin in the game soon... I think it's probably not worth fighting it even if the tools are not as good as VS... seems to be the new paradigm that is here to stay. 

MS knows it that's why they have released Web API. 

At least this is our current thinking, will know more once we have burnt our fingers a bit. :)

Stonie. 

[Michael Ridland]

Hi Adam

If you care about your users experience and then don't use PhoneGap applications. PhoneGap just doesn't cut it, from personal experience and even the best phonegap apps are still clunkly. See http://www.michaelridland.com/mobile/html5-vs-native/

Use Xamarin with MvvmCross, it's fair superior to any other mobile dev option. 

[tarnacious]

Hi nite,

>> I highly recommend the typescript/angularjs/rest webapi stack.

Is this better than a coffee script/backbone/sinatra stack, for example? I

might prefer Flask as a back-end, it is a very simple well organised framework.

>>  massive performance, ux & productivity benefits to doing it all clientside.

Do you have any metrics for any of these statements? I remember arguing to use

Rails over .NET years ago. Maybe you are right that there are benefits, but you

have not demonstrated any.

My advice: 

This is your opinion today, that is great. But before you "highly recommend"

anything please consider your opinions may change. This is a good thing. 

Do not get sucked in to a right/best way to do things fads.

Cheers

Tarn.

[Andrew Stone]

 

@nite If you have any pragmatic tips based on experience around JavaScript MVCs...  I'm keen to hear them! might mean less pain and more gain for those of us exploring. 

PS: Thanks for rousing this list from it's slumber.  :)

Cheers,

Stonie. 

[Jonathan Parker]

This is an interesting discussion.

I've been working on an Android app as a hobby and have ditched Phonegap after having various issues. The biggest reason to switch to native Android was the UI/UX is much better.

For the backend I'm using Firebase which has an Android api.

Has anyone here used Firebase? It seems clunky when it comes to authorisation and doing updates and queries but I like the idea of no server side data access code.

Jonathan
Twitter: @jonathanparker

[Andrew Stone]

FireBase freaked me out because there is nowhere for server side logic AFAIK? (unless perhaps you just use it for crud operations, and run it side by side with a second api server with logic on it - seems like a bad idea however). Plus its pretty expensive IMO... Again it depends on what you are building.  

[Andrew Clancy]

Just quickly, these are really common sense.
Typescript extends js rather than obsfucates it, it really is ES6 with a few type enhancements and features to streamline dev & productivity.
The clientside SPA revolution: once your html, js  & css is down then the only thing going over the wire is json. In my world (grids, charts and lots of data) you cut down times for an equivalent html renders significantly, making the snappy like a native app rather than still seeming like a web site.
Productivity is subjective I guess, I feel the clear separation of presentation and data through physical layers helps, and most of the exciting work going on in web ux is on the clientside community. It more closely follows the architecture of silverlight, wpf flash etc that has proven to work but been blocked from tablets et al, hence needed an equivalent in browser. The server is delegated to what it should be: just the data thanks.

[tarnacious]

>> Typescript extends js rather than obsfucates it, it really is ES6 with a few

>> type enhancements and features to streamline dev & productivity.

I really like (some) static type systems and think they can offer tremendous

benefits. I also use Python, Javascript and Clojure for most of my work, none

of which are statically typed. 

Typescript may be pretty neat, but it's a trade-off. It's an extra compiler

step from plain Javascript, it doesn't improve the syntax or language semantics

like Coffeescript and it doesn't completely abstract the language like GWT and

let you write in Java. 

If you're going to compile to Javascript perhaps consider ClojureScript that

offers a lisp and some immutable data structures which are great for building

software.

>> The clientside SPA revolution

Perhaps you are overstating this. We would probably agree that GitHub is a

pretty nice site. They have pretty charts and awesome code search, hotkeys and

other javascript niceties. It also behaves like a website and is functional

without Javascript. This is a good thing.

>> The server is delegated to what it should be: just the data thanks.

If it could behave like a webserver and also provide assets, headers for

cookies, response codes for when something goes wrong, or has been moved or is

not found, and maybe even some HTML if I navigate to it with my web browser,

that would be great too.