Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Riot next - roadmap to riot 2.3 #1063

Closed
19 of 20 tasks
GianlucaGuarini opened this issue Aug 1, 2015 · 98 comments
Closed
19 of 20 tasks

Riot next - roadmap to riot 2.3 #1063

GianlucaGuarini opened this issue Aug 1, 2015 · 98 comments

Comments

@GianlucaGuarini
Copy link
Member

GianlucaGuarini commented Aug 1, 2015

Riot 2.2.3

The next riot release the 2.2.3 (maybe we could split it also in 2 releases 2.2.4) will fix the mainly the issues raised up by our users

Riot 2.2.4

bugs list

Riot 2.3.0

I would like also to discuss here the updates I've planned for riot 2.3.*

  • rethink/refactore the riot loops to keep them fast but also updating the DOM node correctly
  • remove the compiler, router, observable (maybe also the cli).. from the riot repo. We could publish all these scripts as separate npm modules riot-* and use them to build riot in this repo (or even extend the basic riot functionalities like the router 4 ex.). This solution allows us to split and test all the riot core modules in their own repos avoiding to pollute this repo with too many unrelated tests. Indeed we could also track better the issues related to small parts of our code base. I have already prepared riot-observable containing the folder structure I would like to use also for the other riot modules. Notice that the doc folder could be used to update the whole riot documentation/website here avoiding to rely on @tipiirai on any new riot release. The submodules versioning should be in sync with riot at least for the major releases
  • remove the ie8 support as one of the main riot pros from the doc, I would like explain the hacks about how to use eventually riot on IE8 only in our FAQ section
  • remove the dist folder from the .gitignore to easily debug the release in the dev branch
  • decide whether we want to optimize our build using webpack or keep using smash
    • with smash we could only include the index.js files of all our riot submodules
      • Pros: It will keep the riot codebase small
      • Pros/Cons: Our source files will not be processed by any other tool, they will be only concatenated in riot.js
      • Cons: Use of a deprecated technology
      • Cons: We will lose control over the global variables, functions risking global namespace conflicts
    • with webpack
      • Pros: We can get only the methods exported from our riot submodules keeping, the riot context clean
      • Pros/Cons: We could parse our modules, using babeljs using also es2015 features
      • Cons: Our output will not match the codestyle used in the sourcecode
      • Cons: Our output will be bigger containing extra code generated by webpack to handle the commonjs calls
  • merge the new tmpl.js tmpl.js - complete rewrite (2) #954 version (maybe it could also be a riot submodule riot-tmpl?! )
  • update the riot website automatically on any new riot release enhancing the code [here].(https://github.com/riot/riot.github.io) Do we need to redesign it? Or do you want to keep the current template?
  • enhance the riot-router using the HTML5 history API

Your feedback is really appreciated
@tipiirai @cognitom @rsbondi @aMarCruz

✌️

@davidmarkclements
Copy link
Contributor

davidmarkclements commented Aug 1, 2015

-1 for smash - the implicit globals/locals is bad practice - (confusing, unclear dependencies, tight couplings, hard to maintain module independence)

Is browserify an option? What's footprint of output between browserify and webpack?

Either way sharing the commonjs paradigm between front, back, and isomorphic modules reduces cognitive friction and promotes healthy conventions for frontend logic (which is typically messier due to legacy globals etc)

If we use commonjs and take care not to use node core modules you can use browserify or webpack to build which leaves app developers free to make their own choice (whether they require riot with either)

With regards to AMD - not a fan at all, it adds boilerplate because of the async - but when you build and "optimize" say with r.js you concat everything together again so the async loading is pretty much redundant (lazy loading can be done just as easily and with less code with commonjs bundles)

As for the code output style - why would that be a problem? Is it for debugging purposes? If so We can use sourcemaps to view code for debugging (I know browserify will gen sourcemaps - be surprised if webpack doesn't also).

@aMarCruz
Copy link
Contributor

aMarCruz commented Aug 1, 2015

👍 riot has moving to be a general tool for serious big projects and this is the way.

about using smash. Webpack is a excellent tool, but we can do more with smash if we submit a little PR in their repo with plugin support so we can run other tools on the chain.
This relates to another important point in the growth of riot: the dev documentation... or lack of this.
Any change is complicated and risky without knowing the code really does. We need profusion of comment so we can understand the logic. smash + my rmcomms.js tool can output a clean, lighter combined riot.js for debugging and mantain the comments in their own modules, for reference.
It's simple: @ $(SMASH) lib/riot.js | rmcomms.js > $(DIST)riot.js

We can also use the const 'defines' and the conditional compilation features of uglify for handle shared constant values with performance gains, and strip code used for debugging in production. I'm using this in my local branchs with no issues.

In relation to IE8, I think we must publish maintenance releases of riot 2.x with the IE8 support already existent, and release a 3.0 version with new characteristics (e.g. normalized touch events), no support for IE8 at all, and the needed breaking changes.

In other point the compiler needs re-write and I'm working in this, will handle more complex .tag files and I'm moving code from tmpl to the compiler for pre-compiled expressions with a new format in the 'attribs' parameter of riot.tag() and maybe no need for using brackets() at runtime, giving a lighter riot.js with faster execution at run-time.
It will supports HTML5 (XHTML?), IE9+, and user defined beautifier (uglify, js-beautify, etc).

@aMarCruz
Copy link
Contributor

aMarCruz commented Aug 1, 2015

@GianlucaGuarini , @davidmarkclements, @tipiirai , @cognitom, @rsbondi , all
please write your suggestions about a new compiler in the https://github.com/riot/compiler page.
I will upload a preliminary version soon.

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Aug 1, 2015

@aMarCruz Please make sure to follow the same structure used here folders, dependencies, codestyle, readme ...

@davidmarkclements
Copy link
Contributor

davidmarkclements commented Aug 1, 2015

@GianlucaGuarini @aMarCruz debuggabability of build output is, imo, not a strong enough trade off for allowing implicit localisation and poor module boundaries

Even at that browserify keeps comments in, I'm pretty sure sourcemaps can retain comments too (need to fact check that).

Sourcemaps are a way more standard solution to this problem...

Frameworks tend to model (newer) user behaviour - we want to help devs create good habits and use standard tools right?

@davidmarkclements
Copy link
Contributor

davidmarkclements commented Aug 2, 2015

@GianlucaGuarini @aMarCruz looking into webpack I'm going to go ahead and recommend browserify. since parts of riot are isomorphic it makes sense to use the same module system. the node "flavour" of commonjs differs from latest commonjs (which webpack follows). So in node and browserify its

var myMod = require('myMod')

In Webpack a straight require call is async, it's AMD not common js, so this would potentially load 'myMod' async. For commonjs with webpack you have to wrap sync require calls in require.ensure

require.ensure(['myMod'], function(require) { var myMod = require('myMod'); })

Whilst there's probably a plugin to mimic node behaviour, why bother with extra config when this is standard with browserify (unless webpack has a serious output size advantage)

@davidmarkclements
Copy link
Contributor

davidmarkclements commented Aug 2, 2015

Just to give an example of using browserify (without the need for gulp/grunt etc, just using package.json scripts) take a look at https://github.com/costacruise/atmos/tree/master/app - a blog post about it is here: http://blog.costadigital.io/2015/08/03/how-to-quickly-build-a-social-realtime-application/

Notice how easy it is to use module scope and scoped styles to create completely self contained components

@aMarCruz
Copy link
Contributor

aMarCruz commented Aug 2, 2015

Yeah, I played with Browserify and Grunt time ago, but I'm stay with Brunch by Paul Miller & Elan Shanker (from the backbone.js team).
It is super simple, generates shorter and faster code for CommonJS, no waste bytes, has many plugins. Lints, join, and minimify (uglify) out of the box. Optimizes images, html, css, and uses node.js pipes, with support for source maps over all the chain.
Same config for debug and production versions.
Example from a config (brunch-config.js) for a real app (I wrote this w/Chaplin)

exports.config = {
  files: {
    javascripts: {
      joinTo: {
        'js/app.js': /^app/,
        'js/vendor.js': /^(?!app)/
      }
    },
    stylesheets: {
      joinTo: 'css/app.css'
    },
    templates: {
      joinTo: 'js/app.js'
    },
    devtool: 'source-map'
  }
};

pack ./app/**.js into js/app.js and *.js from others subdirs into js/vendor.js
tool folders are excluded by default.
cons? Brunch uses Bower for download their tools.

@aMarCruz
Copy link
Contributor

aMarCruz commented Aug 2, 2015

We all have different preferences, and this is why I prefer to smash for riot, does what he must do now, and I understood immediately seeing an example, not learning curve. I learn Brunch in two days. Browserify is more complex.

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Aug 2, 2015

Here we are losing a bit the focus. The issue is not really the tool to use but the build strategy and the maintenance of micro modules that could be used independently from riot.
For example riot-observable can be used in riot in 2 different ways:

commonjs (whatever tool browserify, webpack...)

riot.observable = require('riot-observable')

concatenation

// riot-observable/lib/index.js was included somewhere here
// notice that we will include the source index.js and 
// not the dist version in an UMD wrapper 
riot.observable = observable

The same strategy should be applied for riot-tmpl, riot-compiler, riot-router, riot-cli...

@aMarCruz
Copy link
Contributor

aMarCruz commented Aug 2, 2015

You're right. And I stay w/ concatenation, for simplicity. Anyway, users can choose their favorite tool, I don't see any problem here.

@davidmarkclements
Copy link
Contributor

davidmarkclements commented Aug 2, 2015

I think we agree on simplicity as the goal. Concatenation actually leads to complexity because you're not being explicit about available state - commonjs provides appropriate encapsulation that doesn't demand that you know about all implicit state. Then you don't have to know or think about anything outside your module beyond it's exposed interface. And of course as @GianlucaGuarini says it allows for reuse and also replacement because you've loosened the coupling.

I'm loving some of the ideas behind riot - but working with the code base has been a frustrating endeavour - proper encapsulated modules would significantly reduce this overhead and improve the experience of community involvement

@tipiirai
Copy link
Contributor

tipiirai commented Aug 3, 2015

I think concatenation makes more sense on smaller projects like Riot. @davidmarkclements what were the exact pain points? I can see the value here on doing things the standard way, but maybe we could still tackle your issues with concatenation?

Our reason for using SMASH right now is ~30% smaller file size and simplicity (browserify handbook is 37 sheets of printed paper).

@GianlucaGuarini this roadmap looks good, as always.

@aMarCruz glad to see you working on the compiler

@geordee
Copy link

geordee commented Aug 3, 2015

My 2 cents.

I use Webpack for a project that is using Riot. I use the ProvidePlugin to inject riot into every module (à la txchen). After dealing with browserify and custom build scripts for a while, I found Webpack to be the best way to structure and build web application projects today, using Riot or any other library.

Having said that, I guess the question here is how to build Riot as a library. I would agree with @tipiirai in the choice of smash, if it saves headaches. However in the longer run, when Riot is split into modules, that can be included or excluded or built by app developers, I think something like Webpack would be more helpful.

@antonheryanto
Copy link
Contributor

antonheryanto commented Aug 3, 2015

just another useful addition is to uses https://github.com/feross/standard for better style standard which most of it already similar with current riot style with additional tool help and catch simple mistake like undefined variable

@davidmarkclements
Copy link
Contributor

davidmarkclements commented Aug 3, 2015

+1 on standard - it does suit the style (except enforces === instead of == .. which .. is less mistake prone, and more performant)

@tipiirai yah output size should be high priority - that's one of the draws of riot, I think we should have a new discussion about reducing the size in general. However with browserify (and probably webpack) each module is wrapped in similar boilerplate so it should compress will through gzip

The question is, is it worth a size trade off? I think so, within reason.

tackling the issues with concatting will essentially lead to some kind of similar output to webpack or browserify - because one of the primary purposes of commonjs is to tackle those issues.

Here's a list of problems with concatting (along with workarounds)

  • problem: implicit shared state
    • naive solution: wrap an IIFE around every "module", and disallow commits that will leak state to other modules when concatted
    • problems with naive solution:
      • problem: convention has to be enforced
        • solution: use some kind of linting tool to enforce the convention
        • problem: now you have to enforce the use of the linting tool
          • solution: use CI service like travis to automatically rejects commits
          • problem: lot of work
      • plus now you need a way to expose an interface for your module
        • solution: return an object from the IIFE
          • problem: how do we reference the object
          • solution: put each module no a global riot object
            • problem: reliance on an implicit global
              • problem: modules are no longer independent
              • problem:reusability is reduced
              • problem:testing is more complex
              • problem:vulnerability from other scripts running in global space
              • blah blah etc.
            • solution: use a function to load modules by name
              • problem: dep resolution, async or sync etc. etc. etc.
              • solution: CommonJS or AMD

I don't see much value in using concat and then essentially rebuilding a commonjs on top when the problem has already been solved

In terms of webpack vs browserify I think it boils down to configuration vs declarative but the deciding factor should be generated file size

I'm surprised by the notion that browserify is complex, the handbook is 37 pages because it's as much a manifesto as it is a technical guide. @substack is describing an architectural approach and the reasons for doing so - not just technical usage. It's more than worth the read even if you end up not using browserify.

Here's how I browserify a project:

browserify -t babelify -t riotify ./index.js -o build/app.js

The -t flag denotes a transform, so babelify and riotify preprocesses es6 and compiled riot .tag files as modules.

I can put this into package.json scripts

 ...
  "scripts": {
    "build": "browserify -t babelify -t riotify ./index.js -o build/app.js",
  }
...

Then I can do

npm run build

I can also use https://github.com/txchen/light-server to run that task when files change.

That's all there is to it.

@gregorypratt
Copy link
Contributor

gregorypratt commented Aug 3, 2015

  • 👍 for separate repos, management becomes a lot easier
  • 👍 for removal of IE8
  • 👍 for updating the riot website automatically
  • 👍 for enhancing the riot-router

I don't think the website needs a redesign, maybe a bit of a spruce up UX wise, but in general I found what I was after quite easily, and its nice and concise.

Should the Riot website live under riotjs.com rather than muut.com/riotjs/ ? Not to remove the Muut relationship, just switch the redirection.

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Aug 3, 2015

I think we could be ready for riot 2.2.3 I would like to fix the remaining issues in riot 2.3.0

@weepy
Copy link

weepy commented Aug 4, 2015

:+1 for riotjs.com
:+1 for moving riot-router out of the core build

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Aug 4, 2015

riot 2.2.3 is finally out! Thanks to all the maintainers and all our users
@tipiirai @cognitom @aMarCruz @rsbondi

@aMarCruz
Copy link
Contributor

aMarCruz commented Aug 4, 2015

👍 good work

@gregorypratt
Copy link
Contributor

gregorypratt commented Aug 4, 2015

👍 awesome!

@tipiirai
Copy link
Contributor

tipiirai commented Aug 5, 2015

@davidmarkclements I have a feeling that we can find a simple concat- based convention between Riot modules, even so that we can get rid of the riot global. The 30% size increase is not small and we should try to find an alternate solution first and see if it works.

@tipiirai
Copy link
Contributor

tipiirai commented Aug 5, 2015

Still your points are good. Damn –  this is a tough decision.

@tipiirai
Copy link
Contributor

tipiirai commented Aug 5, 2015

@antonheryanto glad you pointed out standard. I wasn't aware that we are almost 100% standards compliant! I almost thought that our coding style is radically different, haha.

@tipiirai
Copy link
Contributor

tipiirai commented Aug 5, 2015

@GianlucaGuarini updated the website. Thank you for the push!

@sylvainpolletvillard
Copy link
Contributor

sylvainpolletvillard commented Aug 5, 2015

What about riot.js.org ? http://js.org offers free DNS and it's easy to get one: http://dns.js.org/

@Mouvedia
Copy link

Mouvedia commented Aug 5, 2015

big 👎 for removal of IE8
👍 on riot.js.org

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Oct 17, 2015

Ok guys you did an amazing work in the last 2 months, riot 2.3.0 is almost ready for a public beta release. I will wait that the 2 main issues/tasks (if activation and the new riot-compiler) will be completed and I will roll out the beta.

cc @tipiirai @cognitom @rsbondi @aMarCruz

@cognitom
Copy link
Member

cognitom commented Oct 18, 2015

@GianlucaGuarini great! It's time to move forward ;-)

This was referenced Oct 19, 2015
@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Nov 1, 2015

riot 2.3.0-beta is out! In a couple of days if there are no big bugs raised up by the community we can roll out the 2.3.0 final release

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Nov 1, 2015

I will start updating the documentation tomorrow

@cognitom
Copy link
Member

cognitom commented Nov 1, 2015

Great! 🎉

@cognitom
Copy link
Member

cognitom commented Nov 1, 2015

I've just update riot-route a bit to v2.3.0beta.4.
(Wildcard behaviour was slightly changed, but no effect on testing)

Anytime I can remove beta from it, if riot-observable do 😄

@MartinMuzatko
Copy link
Contributor

MartinMuzatko commented Nov 1, 2015

Yay :) great work guys

@txchen
Copy link
Contributor

txchen commented Nov 1, 2015

Noticed that the size is now 18.3k in 2.3. Compared to the previous size (12.75k), about 50% increment. It removes the support of IE8, I would expect the size will reduce, however the result is opposite.

May I know what's the reason behind?

@cognitom
Copy link
Member

cognitom commented Nov 2, 2015

Hi @txchen, I'm comparing the submodules, by uglifyjs --comments --mangle | wc -c.
This is not a direct comparison, but it could show some differences (which part getting fat...).

module v2.2 v2.3 incresed (approx) feature added
observable 918 B 985 B +0.1 KB basically same
route 843 B 2038 B +1.2 KB history API, sub routers
tmpl 2249 B 4315 B +2.0 KB more robust
others 10145 B 12180 B +2.0 KB fixes and better loop, etc.

"others" includes:

  • lib/browser/mixin.js lib/browser/tag/*.js for v2.2
  • lib/browser/index.js lib/browser/tag/*.js for v2.3

@txchen
Copy link
Contributor

txchen commented Nov 2, 2015

Thanks @cognitom ! The diff looks reasonable.

The gzipped size is now 7.6KB vs 2.2's 5.3KB, still pretty good, but we can no longer call riot 3kb lib :)

@cognitom
Copy link
Member

cognitom commented Nov 2, 2015

Yeah, I really loved 3kb 😢 but believe it'll be the best vesion 😄

And we must mention about the document translations, too:

And de, nl, es is also on the way.

@tipiirai
Copy link
Contributor

tipiirai commented Nov 2, 2015

The route module can be dropped completely from core on a later version. Should be optional. I think it makes more sense to deal with the UI rendering only similar to React.

@cognitom
Copy link
Member

cognitom commented Nov 2, 2015

Yeah, agreed. At least, we've decided to drop the auto-starting feature of route in v2.3, too. #1301

@gregorypratt
Copy link
Contributor

gregorypratt commented Nov 2, 2015

Also when you've got other options like http://riotgear.js.org/components/router/ ;-) its best to not double up..

@sylvainpolletvillard
Copy link
Contributor

sylvainpolletvillard commented Nov 2, 2015

+1 for separating router from riot. The minimal router is far from suiting every project needs so it makes sense to propose it as an optional plugin.

@a-moses
Copy link
Contributor

a-moses commented Nov 2, 2015

Tools, not policy
"Riot comes bundled with custom tags, an event emitter (observable) and router. _We believe that these are the fundamental_ building blocks for client-side applications "

There is some of contradictory messages over Riot , I think no matter what will be, you must need to think to the long long term! and reorganize ...

  • What are the really true Believes?
  • What are the goals?
  • What are the real Problems in riot?
  • The Size is really an issue? and which Size is to high?
    and so on...

in my opinion you need include very tiny and basic router in Riot core, but is not really matter what I think.

And please remember over time will be harder to change things in the Project (like any Project).

respect you all and WOW Riot is really wonderful (with or without router :) !

Thank You.

@avimar
Copy link

avimar commented Nov 2, 2015

You can go with docker's philosophy: 'Batteries included, but swappable' with links to various community implementation of routers that are easy to use/made for riot, e.g
http://riotgear.js.org/components/router/
https://github.com/TehShrike/abstract-state-router
https://github.com/cognitom/ikki
-> general routers that are popular.
https://github.com/visionmedia/page.js
https://github.com/bytecipher/grapnel

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Nov 2, 2015

I agree that the router must be split from the core but it's funny that before having the html5 router we also got the completely opposite requests from the community :)

@gpoitch
Copy link
Contributor

gpoitch commented Nov 2, 2015

Great job here! If you built the code to be modular (which it is in 2.3.0), I think you should keep things separated. Riot itself is a great view library.

If you want a complete way to build an entire application, create a riot-framework repo that bundles riot+router+observable, etc.

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Nov 2, 2015

@gdub22 observable can not be removed from the core, any riot tag is an observable. We can only eventually remove the router

@tipiirai
Copy link
Contributor

tipiirai commented Nov 3, 2015

Good questions @a-moses. My attempt to answer your concerns.

I no longer think that router is a fundamental building block for client side applications. I have personally build applications without routing. Think of in- page components that doesn't care about browser location for example.

But rendering and logic is part of every UI component.

The goal of Riot is to help developer to build UI components that are easy to understand and reuse. This is the ultimate mission and the ground where the core problems are.

Size is a major benefit for Riot. A compact size is a sign for good programming practises, understandable code and overall simplicity. 3kb is definitely cool, but whether it's 10kb or 20kb is not a thing. 50kb and up makes me feel that there is something wrong with the focus or with the implementation.

I think it makes perfect sense to separate routing from the core. Riot is a highly user friendly tool for building user interfaces and offers a great option for routing, which is a highly common task for todays frontend apps.

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Nov 3, 2015

@aMarCruz @cognitom @tipiirai @rsbondi I wrote in the skype chat the plans for the next 2 riot releases. Resuming it here: we will release riot 2.3.0 as it is we must just update the doc

@a-moses
Copy link
Contributor

a-moses commented Nov 3, 2015

@tipiirai
"The goal of Riot is to help developer to build UI components that are easy to understand and reuse. This is the ultimate mission and the ground where the core problems are. "

This is powerful statement , only this can take entire chapter on Riot book.

Thank you for your effort and investment, and please do not get me wrong I really like and appreciate your wonderful work ,responsibility and creative thinking to built Riot with the ultimate mission, real open source and powerful.

@cognitom
Copy link
Member

cognitom commented Nov 5, 2015

@a-moses thanks for your comment.
Routers could be still fundamental for many apps, but also I can say that routers are replaceable and should be.

Batteries included, but swappable

is true, as @avimar mentioned. Actually, there're hundreds of routers on npm.
But our new riot-route has become more practical for 90% of use-cases and the smallest with such important technologies like history API, I think. Have a try, guys ;-)

@gregorypratt
Copy link
Contributor

gregorypratt commented Nov 6, 2015

Congratulations on releasing v2.3 guys! 👍

@GianlucaGuarini
Copy link
Member Author

GianlucaGuarini commented Nov 7, 2015

closing this issue.. the new roadmap will be published soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests