

Ask HN: How should we write our next JavaScript front end? - y0ghur7_xxx

We are starting 3 new projects that are very heavy and complex on the web frontend side, and we are a bit undecided about how to go about writing the frontend.<p>What we are sure about is that after we write part of the apps and give it some structure, some parts of it will be outsourced to external firms, so we would like to use a JS framework just so that most of the stuff going in will be already documented and done for us (&quot;just use Angular and follow the best practice document here&quot;).<p>Just by looking around our first choice was Angular, but since 1.x is known to be superseded by Angular 2.x, and since 2.x is not here yet, we would like to go with something that we know will be here for the next 2&#x2F;3 years, since we know that the apps will live at least for the next 5&#x2F;6 years.<p>The ideal thing would be a list of JS libraries and a document describing how those libs should be used to work together, and how to structure the code, so that when something better comes out we can just switch a lib and refactor the parts that used that lib to use the new one.<p>Is there something like this out there? Do you have any suggestions?
======
rilita
It sounds as though you are already set on making each system a single page
application. Is there some reason for this beside it being cool and trendy?

If you go the SPA route, you will need developers who are well versed in
whichever JS frameworks you decide to use.

Most applications can be created in the more classic approach, with JS being
limited to what is needed for each page. Those pages can still have crazy
dynamic controls, but generally the idea is to keep the chaos to a minimum.

The best systems are clean and straightforwards. This lends well towards a
classic design approach.

My recommendation would be to not make a SPA, and to just use jQuery and the
pile of widgets that utilize it. Your application will end up running faster
and using less memory as a result. SPA memory leaks are a ____*.

~~~
y0ghur7_xxx
> It sounds as though you are already set on making each system a single page
> application.

No, not really.

> My recommendation would be to not make a SPA, and to just use jQuery and the
> pile of widgets that utilize it.

So hand crafted html? Or would you render html server side? How?

~~~
rilita
The basic structure of the page should be simple div based layout enhanced
with CSS. Any data that must be rendered in JS ( such as dynamic tables ) can
be done by outputting the data in JSON format into the page, and then calling
the JS to construct the table. This is faster than adding a calling to a JSON
resource to get the data for the table. It allows data and page structure to
be sent to the frontend all at once.

The rendered html code can itself be created using a backend HTML templating
system. There are many available. If you want to go hog wild with JS you could
use NodeJS on the backend too; although it isn't well suited to unit testing
imo. Important thing here is to ensure developers don't put HTML output into
the middle of code. Options and rendered values should be passed into a hash
of some sort that is passed into template rendering. Templates can embed
templates etc... Might be acceptable to render SSI includes into your files
for some purposes.

Note that JS related to each page should be contained within a single JS file,
rather then embedded on the page, so that it can be cached by the browser. (
good cache expiration rules should be used in production so that the JS does
in fact get cached for a while )

Toolbars / popups / etc can all be done via straight JS, but you should use
some template language in order to create them, rather than manually making JS
calls to create each node.

If at all possible, page layout should be reused on multiple pages, so that
overall containing style can potentially be changed later separately from the
complex add in JS functionality.

An icon sprite grid should be used for all icons rather than using individual
icons.

Among other reasons for using different pages instead of SPA: 1\. Can use real
URLs for different reachable places in the system, and those can be
bookmarked. 2\. No additional hackery is needed to be able to reach the same
state besides URL 3\. You can unit test individual pages for functionality 4\.
People can concurrently edit different pages without needing to alter the same
files.

In the backend, a routing engine should be used that directs calls to
different modules depending on where you are in the system. Generally it is
easiest to have them be in different files so that you can alter them
independently. ( avoid merge conflicts... )

~~~
S4M
That's some interesting points you are making. Just one question:

> The basic structure of the page should be simple div based layout enhanced
> with CSS. Any data that must be rendered in JS ( such as dynamic tables )
> can be done by outputting the data in JSON format into the page, and then
> calling the JS to construct the table. This is faster than adding a calling
> to a JSON resource to get the data for the table. It allows data and page
> structure to be sent to the frontend all at once.

In html/css are you able to position an element on the page exactly where you
want? I am doing at the moment some web development for maths exercises, and I
couldn't manage to get the positioning right with pure html/css, so I had to
resort to:

    
    
        $("#my_element").offset({"left":x,"top":y});
    

The positioning I want is something non trivial because the elements are
positioned with respect to each other.

I am just nitpicking here, on overall I think your comment is very
informative.

------
iends
Angular 1.x won't magically stop working when Angular 2.0 is released. The
upgrade path from 1.x to 2.0 is not available/clear/whatever but that doesn't
mean that 1.x isn't the best choice right now.

~~~
y0ghur7_xxx
> Angular 1.x won't magically stop working when Angular 2.0 is released.

But it will soon become older and older and with the info we have now it seems
there won't ever be a way to port the code to 2.x. So that would make it a bad
choice for a new project with a lifespan of 5/6 years.

~~~
iends
It is way to early to say there isn't a way to port to 2.0. 2.0 doesn't even
exist.

Again, the code will not stop working magically just because your code is 5/6
years old.

~~~
y0ghur7_xxx
> It is way to early to say there isn't a way to port to 2.0. 2.0 doesn't even
> exist.

That is not what I sad. What I sad is that _with the info we have now_ it
seems there won't ever be a way to port the code to 2.x.

The code of 2.x we saw is completely different from 1.x.

> Again, the code will not stop working magically just because your code is
> 5/6 years old.

You are right, but "the problem is future proofing. What happens when Facebook
releases its Oculus Rift browser and I'm still stuck on Angular 1.2 because of
my IE8 support, but only 2.0 exploits the Rift properly? What happens when
candidates for jobs stop knowing how to use 1.x? What happens when I have to
give this technology to non-FEDs who find themselves confused by the
conflicting documentation and version-less community code? (e.g. stack
overflow snippets that require 2.x but do not say so)? I've seen these
problems with other frameworks outside the front end space (e.g. Spring)."¹

I have been there as well, and I don't want to get there again. At least not
willingly.

¹[http://www.breck-mckye.com/blog/2014/12/the-state-of-
javascr...](http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-
in-2015/#comment-1755300752)

------
argonaut
It seems like you're fairly uncertain of the JS landscape. Just because of
that I say you should use straight up jQuery. jQuery + widgets is rock solid.

I would never commit to a framework like Angular/React without understanding
what SPAs are, their tradeoffs, their alternatives, and their limitations.

It also happens that jQuery probably fits your use case the best.
React/Angular are rather monolithic (and yes, I do understand that React only
dictates the view layer, but still), and are actually probably less
outsourceable.

------
nicklovescode
I know this isn't a direct answer but I'm working on a new framework(that
isn't ready yet) but I would love to hear your thoughts and see what you're
excited by. Couldn't find your email mine is cammarata.nick@gmail.com.

------
cmstoken
Angular is kind of old and outdated so I'd suggest something like React. React
is more robust, and it'll be around for at least 2 years.

~~~
logn
I'd recommend going with something even older and more outdated and with
better support: Java and Freemarker. Java was released 20 years ago and
Freemarker 15 years ago. I'd give them another 30+ years of reliable use.

