Isojs, a build plugin to remove extraneous code for server and client

announce
1

Hey guys,

I am looking for feedback for my new package isojs at https://atmospherejs.com/xamfoo/isojs

Basically, this Meteor package makes sharing code between client, server and mobile better by parsing and removing extraneous code for the server and client. This means code wrapped with if (Meteor.isServer) {...} won’t be served to the client or vice versa. The advantages of this is:

  • Smaller payload for the client, mobile and server
  • Better sercurity since wrapped server code won’t be exposed to the client
  • Slightly better performance due to reduction in extraneous code

Currently, filenames have to end with .isojs to use the package. I was kinda hoping Meteor would allow multiple source handlers in future so .js code can be parsed.

Anyway, thanks for taking the time to look at it.

3 Likes
2

This is a great idea.

What happens to the else block in:

if (Meteor.isServer) {
  ...
}
else {
  ...
}

Does it still get left in non-server code?

3

I thought that this was taken care of when deploying.
Never really looked into it but just assumed.

I don’t have too many places in my code where I have both client and server code separated in the same file. I feel like I try my hardest to keep server code in the /server directory.

edit:
Nice work on the package.
Sounds like something that should be used by default. Would there be any downsides in doing this on every project? Does it impact latency compensation?

4

Very good idea.
I had dreamt long ago of creating a new kind of Meteor Server-Client object, all in one file.
I think is very useful especially for collections (publications , subscriptions and utilities)
Kudos :slight_smile:

5

Good question. When the If block is removed, the else block remains. So the following:

if (Meteor.isServer) {...}
else {doSomethingElse();}

transforms to this in the non-server code:

doSomethingElse();

I have just updated the readme to illustrate how other scenarios are handled. Thank you!

1 Like
6

Latency compensation should not be affected but using a meteor build plugin like this probably increases the build time. Most likely this would not be very noticeable unless there are a lot of files to be parsed.

A possible downside is decreased code readability when a function or method need to do a lot of stuff. On the other hand, it may be easier to maintain code in a single file compared to files in the server and client folder.