
The front end of an example full-stack app built using Vue and Node - tahazsh
https://github.com/TahaSh/vue-forum-app
======
avip
Friendly suggestion:

1\. Add the backend under same repo.

2\. Add a root _docker-compose.yml_ instead of sending interested party to
"install backend".

    
    
      root
        | - frontend
           | - Dockerfile
           | - ... code
           | - README.md
        | - backend
           | - Dockerfile
           | - ... code
           | - README.md
        | - .gitignore
        | - README.md
        | - docker-compose.yml
    
    

Thanks

~~~
oliv__
I agree with suggestion #1 but what do you need to bring docker in for? That's
way overkill. Just have the server side serve the Vue.js app on the main
route.

~~~
salamander014
I understand why people think Docker is overkill, but Docker is a simplified
approach to the most "correct" way to build and deploy applications we've come
up with so far.

Even though simple projects don't necessarily need Docker to work, they are
100 times better off using Docker than doing things by hand, because that
alternative means they are only deploying once and never again (updates, new
environment, dev/staging/prod) and that's just not true.

~~~
dvt
This, of course, sounds good in theory, but then you'll realize that Docker
itself can break six ways from Sunday. Deployment should not be part of, or in
any way linked to, code. I'm not sure why everyone's starting to bundle what
is essentially dev-ops infrastructure with source. I have some old laptops
where Docker doesn't even work, for example (due to a lack of VT-x). Why
should that preclude me from a simple "yarn run" or whatever? It's insanity.

~~~
koboll
>Deployment should not be part of, or in any way linked to, code.

Why?

~~~
dvt
Because deployment tends to be very context-sensitive[1], but code should
almost never be.

[1] Are you running this in the cloud? On Google? On AWS? Cloud functions? A
containerized VM? Maybe you're running it on an old Mac in your basement. If
you're deploying on Linux, you're using lots of bash scripts but -- whoopsie
-- those won't work on Windows.

~~~
avip
[1] You've basically listed the very reason I'm using docker. It makes my code
deployment agnostic. Bash "setup" files? been there. I write Dockerfiles.

I think that's the _only_ thing I'm strongly opinionated about as a developer.

\--- EDIT

This is a classic. Reading the backend "how to run" guide I see:

    
    
      DATABASE=<your-mongodb-connection-string>
      PORT=5000
      SERVER_URL=http://localhost:5000
    

This should settle any debate about docker being "overkill". Developers are
notoriously reluctant to install things on their dev machines. As-is this repo
has non-trivial setup friction which will reduce # of potential users/testers.

TL;DR: _docker-compose up_

~~~
dvt
Like I mentioned, I have laptops that can't even _run_ Docker. I've had to fix
CMOS/BIOS settings to be able to run Docker on my main dev box. Also, running
Docker can sometimes mean not being able to run VMWare (due to virtualization
settings). Not to mention that version controlling Docker repos is a huge pain
in the butt, we've had to call our dev ops guy in the middle of the night
because some random dependency changed some version that broke something down
the line.

Pretending that using Docker is as easy as "docker-compose up" is either
disingenuous, or you simply haven't used Docker as much as I have. Either way,
I still contend that Dockerfiles have no room in a source code repository.

~~~
avip
I'm in agreement with you that docker on windows is less enjoyable an
experience.

btw enabling VT-x is required for other tools as well (Android Studio for
device emulation).

------
y-c-o-m-b
Nice work! Just goes to show how clean and readable Vue code is. I've done
enterprise development with React, Angular, and older stuff like JQuery. Vue
is by far my favorite for its ease of us, minimalist footprint, and
readability.

In a real world situation, I would attach id attributes to the elements for
automated QA testing purposes.

------
thdrdt
I like Vue a lot, but then I discovered Blazor (.NET core + SignalR).

And now I am questioning the whole Javascript ecosystem.

With stacks like Vue and Node I always feel I have to do the same work twice.
Double models, validation in the front end and validation in the back end, and
so on.

With frameworks like Blazor you are much more productive. And I believe this
will be the future of developing SPAs.

~~~
mhd
Reminds me a bit of how we thought about Vaadin or GWT...

~~~
sdfin
Apart from using WebAssembly, is Blazor very different in some way from these
two?

~~~
mhd
Vaadin is a bit higher level, if I remember correctly. It seems to pivot to
work with Web Components these days, some of which might be written in Web
Assembly anyway...

I don't even think that bytecode->WASM and Java->JavaScript should be that
inherently different for frontend purposes. Then again, I never thought we'd
need hyper-optimized JIT compilers for friggin' simplistic UIs, where you'd
think that Microsoft BASIC would be fast enough... (Sure, it's great for
lunning Linux, Quake or Alexa in the browser…)

But I'll try not ending up sounding facetious. From a code quality and ease of
use POV, Blazor might be better, haven't done too much to argue that. And even
rebranding the same technology after a few year's of both Moore's law and
lessened expectations by users/developers is often a big difference from a
marketing standpoint. And that does count, as it increases the community,
which is where a lot of projects fail.

------
petilon
I see some worrisome coding patterns here: [https://github.com/TahaSh/vue-
forum-app/blob/master/src/view...](https://github.com/TahaSh/vue-forum-
app/blob/master/src/views/Category.vue)

    
    
            <base-button
              v-if="isLoggedIn && currentUser.can('own_topics:write')"
              class="new-topic-button"
              :to="{ name: 'CreateTopic' }"
            >
    

There is logic embedded in the view. Does this get compile-time checked
(assuming you used a compiler such as TypeScript)? In my opinion this is the
weak-point of Vue. It is possible to use JSX in Vue. But it is also possible
to use non-compile-time-checked expressions. In React you only have compile-
time-checkable syntax. That's better because when a code is written using
React (by someone other than you) you immediately have some reassurance that
some poor coding patterns are excluded.

~~~
esaym
>There is logic embedded in the view.

What logic is that? The v-if part? I've done a few larger vue apps where users
have many different permissions. I don't see anything wrong with hiding
something on the front end if a user doesn't have the permission. What would
the alternative be? I remember the days of handling permissions via HTML
templating engines... certainly a simple v-if statement in vue is better than
that.

~~~
leppr
You have to read at least up to the third sentence to understand the comment.

~~~
esaym
If the concern is "compile-time checking", then that would be valid as a
string template would not be checked I assume.

------
thekevan
Why is this noteworthy? I'm not saying it isn't at all, but as someone who
doesn't do full stack, how is this different than some of the basic app
example one may do in a tutorial.

I'm sure it's more, it's just not clear to me with my lack of experience in
this area.

~~~
ronilan
_> Why is this noteworthy?_

I'm, obviously, pulling some rabbits out of thin air here but... see this:

    
    
      import Vue from 'vue'
    

Not knowing anything about Vue, you can still guess that Vue is serious magic
just by looking at the way the code for the project is laid out.

That's it.

Ah, but why is it noteworthy?

Cause assume, just for a second, you had a private package, that may also be
able to pull rabbits out of dark places, and you had reasons to keep it
unpublished. Like, you wouldn't want to release the code, not even in bundled
apps. In that case, you would look at this HN item, and repo, and note that,
yes, one can release code for a magic based app without releasing the code for
the magic lib itself. And that this may allow someone at HN to comment _Nice
work! Just goes to show how clean and readable [insert magic lib name] code
is_. And this can start a conversation and lead to opportunities.

And that's worth noting.

But also worth nothing. Cause it's nonsense. You can always do neither.

Edit: I’m not saying this is the reason this specific item is on the front
page or commenting on the repo itself (the code looks solid). I’m just herding
speculative rabbits.

~~~
lucasmullens
I can't really follow all the rabbits here. Vue is just a library, being used
in the same way as any other library.

~~~
ronilan
> _I can 't really follow all the rabbits here._

I apologize for that.

When a rabbit picture is sent over a fax machine, the machine makes a lot of
noise. Unfortunately even if one listens intently, one will not be able to see
the rabbit. The message still goes through though.

~~~
sk0g
I had a rather tough time following this conversation, but loved it thoroughly
:)

------
wiradikusuma
I've been using React for a year or two, and I thought it's my holy grail for
frontend.

Few weeks ago a colleague suggested Vue for a project. Initially I was
skeptical, but as I learn it, my mind is blown. Esp. look at quasar.dev, it's
Vue with batteries included.

~~~
ergothus
I've been a React dev and after a couple of years of being Vue-curious, I
banged around with it a little for a work project.

My reaction was the opposite of yours - I found the syntax to be some
confusing "not really JS" that follows hard-to-discover rules and scoping. It
felt very much like JSP - simple enough if you're just dropping in values, but
as soon as something gets even slightly complex, it gets ugly quick. Error
messages were also far less informative than React (to be fair, React has done
a ton in the past couple of years to improve their error messaging).

Example: In react, if I want a <ui> with a bunch of <li>s, I tend to output a
JSX <ul> with a bunch of <li>s from some JS loop. A 1:1 relationship between
the tags I produce and the tags that are generated. My loop logic is pure JS,
so no surprises there.

In Vue, the syntax is:

<ul id="example-1">

    
    
      <li v-for="item in items"> {{ item.message }}  </li>
    

</ul>

Which seems perfectly readable, but...The "<li> tag doesn't represent what
gets rendered, it's a TEMPLATE of what gets rendered. Can I reference "item"
in another "v-" attribute of the <li>? What happens if I wanted to
conditionally include/not-include an <li> for the list of items?

A list shouldn't be where "complex" problems start. A list should still be
"simple"

My anecdote doesn't beat yours, (and, generally, your anecdote is the more
common one), but I wanted to offer an opposing data point, because I expected
Vue to be less involved than React, and I found the opposite to be true.

~~~
ng12
Agreed completely. My favorite example is the `slot` directive which doesn't
exist in React because the pattern comes for free.

To take the example from the Vue docs:

    
    
        // Component with a slot    
        <ul>
          <li v-for="todo in filteredTodos" v-bind:key="todo.id">
            <slot name="todo" v-bind:todo="todo">
              {{ todo.text }}
            </slot>
          </li>
        </ul>
    
        // Consuming component 
        <todo-list v-bind:todos="todos">
          <template v-slot:todo="{ todo }">
            <span v-if="todo.isComplete">x</span>
            {{ todo.text }}
          </template>
        </todo-list>
    

This can be rewritten in React with much simpler, cleaner code:

    
    
        // Component with a "slot"    
        <ul>
          {filteredTodos.map(todo => props.renderTodo ? props.renderTodo(todo) : todo.text)}
        </ul>
    
        // Consuming component 
        <TodoList todos={todos} renderTodo={todo =>
          `${todo.isComplete ? "x " : ""}${todo.text}`
        }/>
    

Simplicity is key. In the React version you don't have to worry about the
`slot` syntax, build a mental model of how Vue treats it, or risk running into
the limitations of the feature.

~~~
xdanger
I'm not really sure how can you say that the React code is simpler or cleaner?
Where do props come from? Where's the span for x? <li>'s are generated by
magic?

I just don't like mixing html and js like that, maybe that's why it also seems
messy to me.

The vue example also isn't the greatest, some cruft could be removed using
default slot and shorter syntax.

~~~
ng12
Both Vue and React have props. The above code is a snippet; I used the same
format as the Vue documentation (which I agree is a little confusing).

> Where's the span for x?

I assumed Vue was only using the span for v-if, in React we don't need that
extra node.

> <li>'s are generated by magic?

Whoops -- an omission on my part. They should be wrapping the inside of the
mapping function.

> I just don't like mixing html and js like that, maybe that's why it also
> seems messy to me.

But this is where the magic is. It's exactly why React didn't need to invent a
concept for "slots". I admit it's vaguely unfamiliar at first but if it
increases both the power and simplicity of your template it's a no-brainer.

------
cobbzilla
As a backend developer who only sometimes (and reluctantly) dabbles in
frontend code, I found this example to be much more understandable:

[https://jasonwatmore.com/post/2018/07/14/vue-vuex-user-
regis...](https://jasonwatmore.com/post/2018/07/14/vue-vuex-user-registration-
and-login-tutorial-example)

The explanations are great, and the layered structure is nice and clean.

I've tried React and the learning curve was just too high for me. Learning Vue
has been a joy by comparison.

------
hit8run
I prefer Ruby on Rails for these kind of CRUD apps. I see no tests in this
repo and the DB also seems mocked?

------
harrisonjackson
Neat minimal app! Each new page loads fast enough for me that the loaders are
very jarring. Minimal UI improvement might be to remove the loader and just
transition to the view when it is done loading. Show the loader after 200ms or
some amount of time if it is taking unexpectedly long.

------
deltron3030
Is there a way to make the transitions more snappy, maybe with a less linear
transition curve? I suspect that current implementation makes the app feeling
slower than it could be.

------
whycombagator
Clicking reply on a topic prompts a login screen to display, if you then click
signup it just reloads the topic

------
Piisamirotta
Is there a similar for React and Node? Just trying to learn those

~~~
dsego
Try RealWorld example apps:

[https://realworld.io/](https://realworld.io/)

~~~
Piisamirotta
Thank you!

------
BaconJuice
is the auth provided here production ready? what steps do we need to take to
make sure it's got prod ready auth?

------
sharemywin
I didn't get a chance to look deep at your code, but was wondering what your
thoughts were about this article on passport best practices:

[https://hackernoon.com/your-node-js-authentication-
tutorial-...](https://hackernoon.com/your-node-js-authentication-tutorial-is-
wrong-f1a3bf831a46)

