3 ms·

I'm still a bit unsure about these sorts of projects. I like the idea of improving Javascript's rough edges, but whenever I start a new project, I always seem t

I'm still a bit unsure about these sorts of projects. I like the idea of improving Javascript's rough edges, but whenever I start a new project, I always seem to stick with plain old javascript. That said, Spider feels like it is heading in the right direction: - It embraces JS's prototype OOP. I've never liked how CoffeeScript tries to add traditional classes. Not sure the syntax is right, but I appreciate the goal. - It adds just enough "modern" features and syntax to feel like Javascript without requiring me to learn a whole new language. Feels like modularity is missing, though. Is there any support for "require" or "import" or something similar?

alongub 12y ago
I'm still unsure how to add modularity while maintaining compatibility with CommonJS, AMD, etc. I thought about adding a require statement such as: require "vm" require ( "util", "io" ) That would also support git repos, inspired by DuoJS (https://github.com/duojs/duo https://github.com/duojs/duo): require "alongubkin/phonertc"
fizzbatter 12y ago
> Feels like modularity is missing, though. Is there any support for "require" or "import" or something similar? I haven't personally tested it, but i imagine everything is supported, including require and import. It doesn't look like Spider does anything weird to scoping, so to use a global you simply use it with `::global(foo)`, or `use global; global(foo)` I imagine require would be `use require; require('mylib')`, and etc.
- alongub 12y ago
  Of course, but I think he meant native modularity support, which is important IMO.
  - fizzbatter 12y ago
    Isn't that a huge problem to solve though? I don't think i've seen a consistent model for this that suppots both Browser and Server(Node). Node is simple, but Browser has a lot of possible implementations, and a lot of preferences from userspace on how it should technically be implemented. Ie, i have a strong dislike for how RequireJS handles this. I much prefer simply embedding with Browserify and the like. How would you handle this issue, i wonder?
    - alongub 12y ago
      This is a huge issue, and I'm still thinking about it. That's why I didn't add native require support yet. I'm hoping that the community would come up with a good idea.
      - woah 12y ago
        I think you should stay far away. It's a solved problem.

alongub 12y ago

I'm still unsure how to add modularity while maintaining compatibility with CommonJS, AMD, etc. I thought about adding a require statement such as: require "vm" require ( "util", "io" ) That would also support git repos, inspired by DuoJS (https://github.com/duojs/duo https://github.com/duojs/duo): require "alongubkin/phonertc"

fizzbatter 12y ago

> Feels like modularity is missing, though. Is there any support for "require" or "import" or something similar? I haven't personally tested it, but i imagine everything is supported, including require and import. It doesn't look like Spider does anything weird to scoping, so to use a global you simply use it with `::global(foo)`, or `use global; global(foo)` I imagine require would be `use require; require('mylib')`, and etc.

alongub 12y ago
Of course, but I think he meant native modularity support, which is important IMO.
- fizzbatter 12y ago
  Isn't that a huge problem to solve though? I don't think i've seen a consistent model for this that suppots both Browser and Server(Node). Node is simple, but Browser has a lot of possible implementations, and a lot of preferences from userspace on how it should technically be implemented. Ie, i have a strong dislike for how RequireJS handles this. I much prefer simply embedding with Browserify and the like. How would you handle this issue, i wonder?
  - alongub 12y ago
    This is a huge issue, and I'm still thinking about it. That's why I didn't add native require support yet. I'm hoping that the community would come up with a good idea.
    - woah 12y ago
      I think you should stay far away. It's a solved problem.